1

As far as I can see, to develop applications using OAuth we need to own server space to host a site?

An application, when registered to DaniWeb, requires a URL to be provided. A desktop application obviously doesn't have one of these.

When sending OAuth requests we have to provide a redirect URL on the domain we registered the application too, therefore if we dont have the domain as its a desktop application, we cant OAuth, correct?

Only way round figured on the IRC was to own web space to allow a page on a webserver as intermediairy for the redirect to go to.

Is this the intended case?

Edited by Mike Askew

4
Contributors
25
Replies
130
Views
4 Years
Discussion Span
Last Post by Dani
Featured Replies
  • OAuth is pretty bad for native apps, whilst maintaining the trust of your users. There's ways around it of course, but none of them lead for a good user experience. Unfortunately nothing can be done about that :( Read More

  • 1
    Dani 1,665   4 Years Ago

    OK I'm reading through the code that generates the access token and here is a list of all possible reasons why you'd be getting that error: * The client_id being passed in is wrong or doesn't exist * The owner of the client_id (aka you) doesn't have permission to use … Read More

  • 1
    Dani 1,665   4 Years Ago

    When using implicit (clientside) flow: * redirect_uri must reside on same domain as was used to register the application When using explicit (serverside) flow: * redirect_uri does not need to reside on same domain as was used to register the application * redirect_uri passed in to retrieve code must be … Read More

  • 1
    Dani 1,665   3 Years Ago

    We now have a new flow that allows for desktop applications!! :) Simply specify oob as the redirect_uri. Read More

0

As far as I can see, to develop applications using OAuth we need to own server space to host a site?

Not necessarily. It depends what your application is trying to do.

An application, when registered to DaniWeb, requires a URL to be provided. A desktop application obviously doesn't have one of these.

From what I understand, you can embed a browser into your application. It doesn't require server space on your end. I've seen this done many times before, and this is actually what Windows 8 does to handle its Connect to Facebook integration for mail and contacts.

0

Even with embedding a browser into the application I would still need a URL to register the application on, and redirect too, as the API checks the url registered against when an OAuth call is made according to the documentation?

0

as the API checks the url registered against when an OAuth call is made according to the documentation

Only as a security precaution with the Javascript clientside flow, since we can't use secret keys with Javascript because anyone can view source to see them and they won't be secret.

This check isn't done with the serverside flow that uses the secret key.

0

Dani, you said "The protection for server-side is in the client_id and client_secret and the protection for client-side is in the client_id and having all requests originate from the same domain as you specified for the application URL when you registered the app with us", which IMO states I need to request a token from the domain I registered with. I cannot do this with a desktop application unless I fake the header (if that is enough), or use a website as an intermediairy.

Updated to your reply. If this check is for Js only, then it wouldn't matter what I specify as a redirect URI, right? Or can it be omitted?

Edited by pritaeas

0

The protection for server-side is in the client_id and client_secret

This is non-Javascript requests

the protection for client-side is in the client_id and having all requests originate from the same domain as you specified for the application URL when you registered the app with us

This is Javascript requests

If this check is for Js only, then it wouldn't matter what I specify as a redirect URI, right? Or can it be omitted?

You still need to provide a redirect URI because the application still needs to know where to redirect the user back to after they authorize you. However, this can be faked if you read up about OAuth for native apps.

1

OAuth is pretty bad for native apps, whilst maintaining the trust of your users. There's ways around it of course, but none of them lead for a good user experience. Unfortunately nothing can be done about that :(

0

Dani. I've been trying to get a token using Delphi, but it keeps failing. Is there a way to detect what's the cause? I would love to know the reason it fails, so I can fix it.

0

I don't know Delphi for anything, but if it fails and you issued a JSON request, it will send back an HTTP status code along with a webpage telling what the error is. If you issued a JSONP request, it will send back a JSON object with an 'error' field detailing what the error is.

0

It fails on retrieving the token, am not talking about additional requests. The only thing I get back is a webpage telling me "oops, failed to get an access token".

0

That means that it failed to exchange the code for an access token for some reason. I'm on the phone but I'll check it out as soon as I get off.

1

OK I'm reading through the code that generates the access token and here is a list of all possible reasons why you'd be getting that error:

  • The client_id being passed in is wrong or doesn't exist
  • The owner of the client_id (aka you) doesn't have permission to use the API because they are banned, etc.
  • The client_secret passed in doesn't match up with the client_id
  • The code being passed in is wrong

The code parameter is based off of your client_id AND redirect_uri so be sure the same redirect_uri is used to fetch the code as is being passed into the subsequent request to fetch the access token.

Edited by Dani: Typo

Votes + Comments
Thank you for item no 4.
0

I can rule out 1, 2, and 3 (copied from the working PHP class).

I'll have another look at item no. 4. Update: This appears to be the issue. Am getting my own webpage now as expected. Thanks for pointing this out.

Edited by pritaeas

1

When using implicit (clientside) flow:

  • redirect_uri must reside on same domain as was used to register the application

When using explicit (serverside) flow:

  • redirect_uri does not need to reside on same domain as was used to register the application
  • redirect_uri passed in to retrieve code must be the exact same as redirect_uri passed in to retrieve access_token
1

We now have a new flow that allows for desktop applications!! :) Simply specify oob as the redirect_uri.

0

It was an easy fix. Unfortunately, I wasn't aware of this OAuth flow until Sanjay mentioned it to me.

0

I'm not sure since when, but my API (web) client stopped working. Don't ask for specifics yet, because I need to debug first. My login page stops after I get the code back, that's all I know for now. A bit strange because it was still working earlier this week.

0

Very strange. Please let me know. And please start a new thread about it instead of piggybacking this one. :)

0

piggybacking this one

Am just doing what everyone does ;) Picked the wrong thread, I meant to reply in Sanjay's one, or yours.

Edited by pritaeas

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.