3

This is the URL that I'm entering (in Safari, cleared website data and cache; my app, uses own Cookie jar; and incognito chrome) https://stackexchange.com/oauth/dialog?client_id=23&scope=read_inbox&redirect_uri=https://stackexchange.com/oauth/login_success

This is the URL of the page that appears (the address changes in the address bar, but it looks like it's the only page visited)

https://stackexchange.com/oauth/dialog?client_id=23&redirect_uri=https%3a%2f%2fstackexchange.com%2foauth%2flogin_success&scope=read_inbox&response_type=token&state=&returnurl=%2foauth%2fdialog%3fclient_id%3d23%26redirect_uri%3dhttps%253a%252f%252fstackexchange.com%252foauth%252flogin_success%26scope%3dread_inbox%26response_type%3dtoken%26state%3d

This means I get stuck on the authorising page, (or occasionally is says "You're now being returned to the app")

This only happens if the user is not logged in. If the user is logged in, authorisation flys through like it should.

I think this is a variation of this question: Implicit OAuth flow is not working when the user is not logged in.

Or maybe identical. One of the users of my app had this problem though it seemed to have cleared. I've tried different browsers and clearing cache, but the same problem occurs.

Improve this question
6
  • I can't reproduce this. In all my browsers (including Safari) I end up on /oauth/login_success with an access token and expiration in the hash. Your example includes the same redirect_uri both times, a returnurl is being added in the second case. Commented Feb 20, 2012 at 22:38
  • As far as I'm aware the API sets the returnurl parameter? Because the final page is this one: stackexchange.com/oauth/…, where it says you are being returned to StackInbox. But I never get to the redirect_uri. Commented Feb 20, 2012 at 22:48
  • the behavior of the api is subject to change save for the entry point (/oauth/dialog) and the destination (whatever was passed as redirect_uri). The returnurl being set is an implementation detail relating to allowing anonymous users to login as part of approving an app. The link in your comment is just to a "please approve this app" page, which seems correct to me? Commented Feb 20, 2012 at 22:55
  • When the login process stops this is the HTML which appears: pastebin.com/R6GG1t3Y, although the javascript stackauth function has the correct URL in it, this is the URL that the page is (I've tried it with Charles proxy to make sure it's not just my app giving the wrong url) stackexchange.com/oauth/…. Now Safari and Chrome have started performing the login correctly (intermittently) Commented Feb 20, 2012 at 23:10
  • Hmm, sounds like connectivity issues to stackauth.com. I'll make some changes, odd that it's intermittent though. Commented Feb 20, 2012 at 23:19
  • same, and other, issue for me. just had not the time at the time to figure out whether i was 'doin it wrong' or what. thanks for raising this. Commented Feb 28, 2012 at 16:42

1 Answer 1

Reset to default
1

A fix for this has been deployed.

For some people it looks like communication with Stack Auth (for global login) was breaking down, causing the final redirect to not happen. I've slapped a timeout on the attempt to communicate with Stack Auth, after which we give up and do the final redirect anyway.

Users so affected won't get global login sessions (nothing we can do about that), but they should still be able to authorize applications.

Improve this answer

7 Comments

This still appears to be an issue when logging in using StackExchange credentials. The OAuth URL (stackexchange.com/oauth/…) that we use consistently fails to hit the redirect URL on successful login when using StackExchange and sometimes Yahoo! userid's and passwords, and seems to consistently work for GMail and facebook credentials.
@Lee - that should be fixed now, a redirect step was getting dropped under some circumstances on stackexchange.com.
Right now, we're getting "error: invalid_request, error description: OAuth request must be over HTTPS" when trying to log in using gmail, yahoo, and facebook. This is reproducible in our app's webview as well as desktop Safari. This is actually a slightly different issue from what we experienced yesterday. Is anyone else experiencing this?
@Lee try again now, think I found what was breaking those requests. Weird interplay between our SSL accelerator and some (external this time) OpenID/OAuth redirects.
thank you for digging into this. Everything appears to be working great now!
|

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.