Bug #15426

auth.curoverse.com login loop in Firefox

Added by Peter Amstutz over 2 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
-
Category:
-
Target version:
Start date:
06/27/2019
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
-
Release relationship:
Auto

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


Subtasks

Task #15427: Review 15426-login-loop ResolvedLucas Di Pentima

Associated revisions

Revision c8be990c
Added by Peter Amstutz over 2 years ago

Merge branch '15426-login-loop' closes #15426

Arvados-DCO-1.1-Signed-off-by: Peter Amstutz <>

Revision a0507caf (diff)
Added by Peter Amstutz almost 2 years ago

Merge branch '15426-login-loop' closes #15426

Arvados-DCO-1.1-Signed-off-by: Peter Amstutz <>

History

#1 Updated by Peter Amstutz over 2 years ago

  • Status changed from New to In Progress

#2 Updated by Peter Amstutz over 2 years ago

  • Target version set to 2019-07-03 Sprint

#3 Updated by Peter Amstutz over 2 years ago

  • Description updated (diff)

#5 Updated by Peter Amstutz over 2 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.

#6 Updated by Lucas Di Pentima over 2 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!

#7 Updated by Peter Amstutz over 2 years ago

  • Status changed from In Progress to Resolved

#8 Updated by Ward Vandewege about 2 years ago

  • Release set to 26

Also available in: Atom PDF