-
-
Notifications
You must be signed in to change notification settings - Fork 416
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to reselect Google account #103
Comments
Deleting the CSRF cookie should be enough - I have noticed that this is a bit of a bug though (the cookie should deleted if the flow fails). At the moment, if I do this I just type my original request in again to start the flow again I think if we complete the new redirect validation in #77 (I have picked this up this week) then this should be a safe and expected behaviour? |
Can you repro that deleting the cookie does NOT do anything and the cookie just gets set again on the next load of the Not Authorized page? I can repro in both Firefox and Chrome. |
I was curious what was going on under the covers so I snooped on the traffic with Fiddler. Here's what I'm seeing:
At no point was I given the Google login prompt, I progressed through all the steps above automatically. |
Okay so one more tidbit: I don't understand what is maintaining my being logged in here, and I can't find any affordance in the OAuth spec for the requesting server (as opposed to the authorizing server) to reject the token based on the credentials, so I don't know how this is supposed to work. I'm sure you know how the flow progresses and what is going wrong here, but I'll add one more tidbit I'm seeing: Google's API has an affordance for the requester to specify that they'd like to retrigger the account select. By specifying |
Yep, the default behaviour by Google is to automatically select the last selected auth if the session is still active. There's an argument that So, I think this prompt should be added by default - happy for any other feedback! |
I was actually thinking it would happen whether the cookie was removed or not as long as the user wasn’t authorized despite receiving a token successfully from google. You’d have to prevent a redirect loop because on the initial failure you’d want to show Not Authorized but on subsequent navigations you’d want to provide the account selector. I think. Right now the behavior for my users is “get stuck on 403 page and have no recourse” so anything would be better than that. |
Yep, my first comment regarding deleting the CSRF cookie was wrong - google will maintain the account previously selected until the session expires (so you just have to wait). I would like to make This is a change in behaviour, but I don't believe it's "backwards incompatible" as I view the current situation as a bug, so I will aim to land this soon. |
That roughly sounds good but there's one piece I'm missing: when will you trigger the redirect to Google's auth server and when will you let them through to the Not Authorized page? Will you ALWAYS send unauthorized users back to the Google auth server with Thanks again btw for both this package and investigating this issue with me. It is extremely appreciated. |
If a user picks the wrong Google account or just doesn't have access, they'll get a "Not Authorized" 401. How do they reattempt authorization at that point?
I tried manually deleting the _forward_auth cookie both from example.com and oauth.example.com (I am using an AUTH_HOST as I have lots of subdomains) and that didn't work. Where else does this cookie persist? Can I somehow provide a "try again" button?
The text was updated successfully, but these errors were encountered: