Skip to content

Set SameSite=Lax for cookies #1300

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.

Sign up for GitHub

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

Merged
pkarman merged 1 commit into from
Mar 31, 2017
Merged

Set SameSite=Lax for cookies #1300

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion config/initializers/secure_headers.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -44,8 +44,13 @@
config.cookies = {
secure: true, # mark all cookies as "Secure"
httponly: true, # mark all cookies as "HttpOnly"
# 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
Copy link
Copy Markdown
Contributor

@jessieay jessieay Mar 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor

@pkarman pkarman Mar 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my tests the presence of request_id in the URL did not make a difference.

Copy link
Copy Markdown
Contributor Author

@monfresh monfresh Mar 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

@monfresh monfresh Mar 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

@jessieay jessieay Mar 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 🍒

# will be sent to the profile page instead of back to the SP.
samesite: {
strict: true # mark all cookies as SameSite=Strict.
lax: true # mark all cookies as SameSite=Lax.
},
}

Expand Down