-
Notifications
You must be signed in to change notification settings - Fork 685
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
Add SameSite=None and secure to App Session #851
Conversation
Hey @jenshenny Is this work needed after the additional work being added to Rack and Rails? |
This work can do without the bump to Rack 2.1.0 and the additional work in Rails. Originally, I was trying to change the session option of |
3dec2c0
to
c57ef40
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Decided to add a middleware as setting the session option to
same_site: :none
isn't applied to set-cookie headers forshopify_app
assets and/auth/shopify
(omniauth)
Could you expand on that? Why it doesn't work for auth and the assets?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach looks good for now. In the future I think it would be better if we were able to set this on the session, but given the timeline (Feb 4), we should do this ASAP so app developers have as much time as possible to fix their apps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One additional comment, building off Rafael's observation.
I don't believe that this is a blocker on this PR being merged and think that if it will take significant time to implement we should ship a version so developers can start adopting it.
8605342
to
904173b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good work! However I just have one touchup I would like to see. I appreciate the added configurability.
0ba1329
to
160d187
Compare
2e80ab0
to
3a241a2
Compare
Is this affecting redirects to |
@netwire88 Please open an issue. |
@jenshenny just wanted to thank you for this PR. It's well written and the tests do a good job of documenting what I needed to do. Our app (Parcelify.co) has been around a while, and as such it was less obvious for me were to hook things up. Your PR pointed me to the solution. 👏 |
Background
In Chrome 80, the default value of the
SameSite
cookie property will switch fromNone
toLax
(more details here). This means that all iframe'd and cross-origin non-GET requests will not send cookies, meaning that it will break embedded app functionality (you can try enabling the SameSite None flag and accessing an embedded app in your admin)Additionally,
SameSite=None
(which we do not use today) is unfortunately interpreted incorrectly by specific browsers, so this PR handles such situations as well.Changes
Added a middleware that sets all app sessions to
SameSite=None
andsecure
if the browser is compatible and the app is an embedded app.Decided to add a middleware as setting the session option to
same_site: :none
isn't applied to set-cookie headers forshopify_app
assets and/auth/shopify
(omniauth)Tophatting
Tophatted with a new shopify app (where
_example_session
has secure and SameSite None.Also tophatted with one of our first party embedded apps Exchange (though I removed the
ShopifyApp.configuration.embedded_app == true
check to test as Exchange runs both as an embedded app and non embedded app). Also tophatted with the user agentMozilla/5.0 (iPad; CPU OS 11_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Tablet/15E148 Safari/604.1
.If the session already has
secure
andSameSite
set, asecure
andSameSite
will still be appended to the end of the set-cookie header. I personally don't think it's a huge problem as the browser ignores the previoussecure
andSameSite
in the header, but would love to get more opinions on it.