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.
    – Kevin Montrose
    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.
    – Jonathan.
    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?
    – Kevin Montrose
    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)
    – Jonathan.
    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.
    – Kevin Montrose
    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.
    – Sky Sanders
    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
  • 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 Fastenau
    Commented Mar 28, 2012 at 20:02
  • @Lee - that should be fixed now, a redirect step was getting dropped under some circumstances on stackexchange.com.
    – Kevin Montrose
    Commented Mar 29, 2012 at 0:26
  • 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 Fastenau
    Commented Mar 29, 2012 at 20:23
  • @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.
    – Kevin Montrose
    Commented Mar 29, 2012 at 21:30
  • thank you for digging into this. Everything appears to be working great now!
    – Lee Fastenau
    Commented Apr 2, 2012 at 17:14
  • Trying to authorise StackAlert, I get stuck at a popup which advises "This app needs these permissions ..." and tells me that "You need to login to authorize this application". I'm already logged into StackExchange in a different browser tab. Logging out then back in doesn't help. What else should I try?
    – Beetroot-Beetroot
    Commented May 16, 2012 at 2:24
  • This might be completely unrelated but for a completely separate thing (Google Chrome2Phone extension) I encountered an OAuth page not completing redirect and it turned out the time zone was set wrong on my computer, after fixing it the redirect worked as normal: code.google.com/p/chrometophone/issues/detail?id=319#c64
    – Christopher Galpin
    Commented Apr 22, 2013 at 16:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .