Conversation
**Why**: - There is a bug in Chrome that causes the session to be reset in the following scenario: - Set cookies to use SameSite=Strict - Have Gmail open in a tab - In a different tab, visit sp.qa.login.gov and click Login.gov - Click "Get started" and enter your Gmail address - In the Gmail tab, click on the confirmation link in the email - In this new tab that was opened, complete the account setup Result: You are redirected to the profile instead of `sign_up/completed` We had originally set the setting to `Lax` due to this Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=619603 See #189 Because that bug was closed in July 2016, we thought that it was safe to go back to `Strict`, but it sounds like this might be a different bug, or perhaps that original one hasn't really been fixed. This bug only happens in Chrome, and seems to only happen when you click the confirmation link from Gmail. If you copy and paste the link in a new tab that you open manually, the redirect back to SP works fine. Similarly, if you click the link from a non-Gmail email website, it doesn't reset the session when it opens a new tab. I only tried fastmail.com though.
|
cc @konklone |
| # We need to set the SameSite setting to "Lax", not "Strict" due to a bug | ||
| # in Chrome that resets the session in the new browser tab that opens when | ||
| # the email confirmation link is clicked. Resetting the session means losing | ||
| # all the SP info we stored there, meaning during account creation, a user |
There was a problem hiding this comment.
what about passing the request_idin the URL params and deriving the SP info from that? We are already doing that in some places, figure it's possible to use the same technique to preserve SP info outside of session?
There was a problem hiding this comment.
In my tests the presence of request_id in the URL did not make a difference.
There was a problem hiding this comment.
Yes, we would need to change the point in time where we update the session from EmailConfirmationsController to PasswordsController. What's happening is that Chrome is undoing what we set after the confirmation link is clicked. Since we still include the request_id on the /sign_up/enter_password page, we can set the session once the password is entered.
For now, this is the easiest fix, given that the RC has pulled out my changes from #1265.
Some of us have spent most of the day tracking down this issue that was reported by our partner agencies, and we thought it might have been due to my changes, but it turns out it was a Chrome bug that was exposed due to our change of this cookie setting.
Even though my code probably works fine, we feel it's safer to launch without it, then have more time to test it thoroughly before deploying it.
There was a problem hiding this comment.
Clarification: assuming the OpenIdConnect account creation flow works from a mobile app, then we can launch without #1265. Otherwise, we'll need to put it back in.
There was a problem hiding this comment.
Yes that makes sense -- do the easy fix now, potentially re-introduce the more secure secure headers setting later alongside a refactor that includes the request_id param in more places so we aren't so reliant on the session 🍒
**Why**: - There is a bug in Chrome that causes the session to be reset in the following scenario: - Set cookies to use SameSite=Strict - Have Gmail open in a tab - In a different tab, visit sp.qa.login.gov and click Login.gov - Click "Get started" and enter your Gmail address - In the Gmail tab, click on the confirmation link in the email - In this new tab that was opened, complete the account setup Result: You are redirected to the profile instead of `sign_up/completed` We had originally set the setting to `Lax` due to this Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=619603 See #189 Because that bug was closed in July 2016, we thought that it was safe to go back to `Strict`, but it sounds like this might be a different bug, or perhaps that original one hasn't really been fixed. This bug only happens in Chrome, and seems to only happen when you click the confirmation link from Gmail. If you copy and paste the link in a new tab that you open manually, the redirect back to SP works fine. Similarly, if you click the link from a non-Gmail email website, it doesn't reset the session when it opens a new tab. I only tried fastmail.com though.
3 participants
Why:
There is a bug in Chrome that causes the session to be reset in the
following scenario:
Result: You are redirected to the profile instead of
sign_up/completedWe had originally set the setting to
Laxdue to this Chrome bug:https://bugs.chromium.org/p/chromium/issues/detail?id=619603
See #189
Because that bug was closed in July 2016, we thought that it was safe
to go back to
Strict, but it sounds like this might be a differentbug, or perhaps that original one hasn't really been fixed.
This bug only happens in Chrome, and seems to only happen when you click
the confirmation link from Gmail. If you copy and paste the link in a
new tab that you open manually, the redirect back to SP works fine.
Similarly, if you click the link from a non-Gmail email website, it
doesn't reset the session when it opens a new tab. I only tried
fastmail.com though.