Bug #15426
closedauth.curoverse.com login loop in Firefox
Description
Since yesterday (June 25) I can't log in with Firefox 67. I go to auth.curoverse.com, which redirects me to Google, after logging in to Google, it sends me to auth.curoverse.com, at this point it is supposed to send me back to the API server, but instead it sends me back to Google.
The broken flow:
302 auth.curoverse.com/users/auth/google_oauth2/callback?
302 auth.curoverse.com/auth/josh_id/authorize?
302 auth.curoverse.com/auth/josh_id/authorize?
302 auth.curoverse.com/users/sign_in
302 auth.curoverse.com/users/auth/google_oauth2
Strangely, the 1st authorize sends it back to the exact same URL. The cookie is different between the requests. Apparently the 1st request should have sent it to the API server at 4xphq.arvadosapi.com/auth/joshid/callback .
Logging in with Chromium 73 works.
The working flow:
302 accounts.google.com/signin/oauth/consent
302 auth.curoverse.com/users/auth/google_oauth2/callback
302 auth.curoverse.com/auth/josh_id/authorize
302 4xphq.arvadosapi.com/auth/joshid/callback
Updated by Peter Amstutz over 5 years ago
- Status changed from New to In Progress
Updated by Peter Amstutz over 5 years ago
- Target version set to 2019-07-03 Sprint
Updated by Peter Amstutz over 5 years ago
15426-login-loop @ sso-provider|4edf2cce6f2423fb29fa5c5d57f16c2b82f25c58
Updated by Peter Amstutz over 5 years ago
So I don't really know why this still works for most people. My best theory is that there is some bug or race condition relating to the devise "session timeout" feature that causes it to be bypassed in the majority of cases.
Updated by Lucas Di Pentima over 5 years ago
15426-login-loop LGTM (tested locally on arvbox). I personally think that explicitly logging out after redirecting is a much more elegant solution. Thanks!
Updated by Peter Amstutz over 5 years ago
- Status changed from In Progress to Resolved
Applied in changeset sso-provider|c8be990ca10d49424c595f40ca7b43a853724a62.