I don't have any experience with non-web based languages

And I only really have experience with non-web based languages. But I saw my friend write a program in python using a c library to access our university's API and he made a decent app with it. Since it was a simple static linked c library I know that it must be possible, I just have no idea how. I am certain that somebody on this forum knows how to do such a thing. Its just a matter of having them see it. I am wondering if I should post here, or in Software Development to get the help I need.

In order to get a client id so that we can access the api the registration process requires a web address. If the program is going to be PC based there is no web address. Can we register without a web address?

Labdabeta, post your question in the appropriate Software Development forum but tag the thread daniweb-api

Anyone out there working on something juicy for the competition?

Have started on a next example, but it's far from juicy.

Not anymore, my idea swiftly went under with the aforementioned OAuth issues.

There isn't much worth developing that doesn't use OAuth features that I can think of at present :(

Wait ... remind me ... what are the OAuth issues?

Not issues as such, wrongly chosen word.

The use of OAuth on native applications and how it is not friendly for us. But I'm not trying to re-open that debate!

Are you talking about the debate about it being designed for web-based applications?

I stick by my argument that it was determined (and I think that inherently many of you guys agree) that OAuth was the best route to go down for our API, and we adhere to the OAuth standards. I know that there are a good number of native apps and mobile apps that utilize OAuth, but I personally have no experience with writing native apps.

I'm not sure if you'd call what I'm doing for the competition juicy, but it's pretty cool I think. And I'm not really using Oauth. So if everyone seems to be aiming in that direction, I wonder if that means I might have a pretty good chance.

Excited to see it!

As I understand it $current_url would be storing the redirect address back to the page the user was viewing before the call was made in this situation?

I could be completely wrong though. client_secret is seperate if I understand your meaning correctly

AD, you can use that URL to trap a redirect to it, confirming successful login/token. I've bookmarked an SO thread a while back showing how to do just that.

In my web browser example, $current_url is the webpage that initiated the call to the API, and subsequently the webpage that the API should redirect the user back to after authenticating them.

For example, the parameter is called current_uri but the variable $current_url is defined earlier in the example:

$current_url = 'http://'.$_SERVER['HTTP_HOST'].$_SERVER['PHP_SELF'];

That makes no sense in a c++ program, so I guess I can just ignore it. c++ programs don't have web pages.

You can't just ignore it in order to use OAuth :) As pritaeas suggests, you can trap it somehow.

I came up with a solution for native apps that comform with the morals and specification of OAuth, unfortunately there was a single point of weakness in it which meant I had to createa secondary authorisation system, rendering the entire system useless. I abandoned it.

Question Dani; Do you require that URIs begin with http[s]:// ?

It is not required, but it does make that assumption.

Firstly, in order to fetch the code parameter (that can be exchanged for an access token), it will be tacked on as a query string to the redirect URI.

Secondly, it does a check to see if the URI begins with http://, and if it doesn't, it assumes that it is a relative URL and tacks http://www.daniweb.com/ onto the beginning of the URL, so you'll end up with something like http://www.daniweb.com/foo://bar/baz

Is that part of the specification? It not doing that would be very helpful for mobile/native devs ;)

Investigating right now ...

It seems to be the way that Facebook does it but not the way that Google and some others do it. Still investigating ...

The only reason I make the suggestion is that mobile browsers can activate applications based on a registered URN. So for example; if we sent a redirection uri of daniweb://GetToken/ your responder would redirect the browser to daniweb://GetToken/?code=blaaaaaaa which our application would be able to collect as part of the incoming arguments.

This also works on desktop machines, provided you give the browser permission to do so. This overcomes the limitation of having to have an actual website to pick up the Code (as the redirects aren't picked up by the Windows Embedded Browser controls)

If not, no problem, just thought it might help :)

OK, the redirect_uri is no longer mangled if it has a scheme other than http://

What was the result of your investigation btw? I'm curious about what you found out :)

Oh, I was investigating whether I indeed was or wasn't following OAuth standards, and the result of my investigation is that while I was following Facebook's OAuth implementation, Google's implementation is much more friendly towards native non-web based apps.

Facebook however have custom libraries written internally/externally that make their implementation easier to follow (ie. here). How does Google's implementation differ?