Skip to content
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

Merged
merged 4 commits into from
Jan 14, 2020
Merged

Add SameSite=None and secure to App Session #851

merged 4 commits into from
Jan 14, 2020

Conversation

jenshenny
Copy link
Contributor

@jenshenny jenshenny commented Jan 11, 2020

Background

In Chrome 80, the default value of the SameSite cookie property will switch from None to Lax (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 and secure 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 for shopify_app assets and /auth/shopify (omniauth)

Tophatting

Tophatted with a new shopify app (where _example_session has secure and SameSite None.

image

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 agent Mozilla/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 and SameSite set, a secure and SameSite 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 previous secure and SameSite in the header, but would love to get more opinions on it.

@tanema
Copy link
Contributor

tanema commented Jan 13, 2020

Hey @jenshenny Is this work needed after the additional work being added to Rack and Rails?

@jenshenny
Copy link
Contributor Author

jenshenny commented Jan 13, 2020

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 same_site to :none in the app which then would need the bump in Rack, but there were many unusual areas where the Set-Cookie header didn't apply the session option change. I figured it would be much simpler to manually change the Set-Cookie header myself.

@jenshenny jenshenny marked this pull request as ready for review January 13, 2020 17:09
@jenshenny jenshenny requested a review from a team as a code owner January 13, 2020 17:09
Copy link
Member

@rafaelfranca rafaelfranca left a 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 for shopify_app assets and /auth/shopify (omniauth)

Could you expand on that? Why it doesn't work for auth and the assets?

lib/shopify_app/engine.rb Show resolved Hide resolved
Copy link
Contributor

@JackMc JackMc left a 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.

lib/shopify_app/middleware/same_site_cookie_middleware.rb Outdated Show resolved Hide resolved
Copy link
Contributor

@JackMc JackMc left a 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.

lib/shopify_app/middleware/same_site_cookie_middleware.rb Outdated Show resolved Hide resolved
@jenshenny jenshenny force-pushed the same_site_none branch 3 times, most recently from 8605342 to 904173b Compare January 13, 2020 21:46
Copy link

@dmcvittie dmcvittie left a comment

Choose a reason for hiding this comment

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

👍 + 🎩'ed on the Launchpad app.

SameSite = None & Secure is set as expected
image

Copy link
Contributor

@tanema tanema left a 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.

lib/shopify_app/configuration.rb Outdated Show resolved Hide resolved
@JackMc JackMc merged commit b97005b into master Jan 14, 2020
@JackMc JackMc mentioned this pull request Jan 14, 2020
@JackMc JackMc temporarily deployed to rubygems January 14, 2020 18:45 Inactive
@netwire88
Copy link

Is this affecting redirects to confirm_recurring_application_charge URL? Currently, it works if the redirect is handled in a non-embedded app browser window, but in the embedded app browser window, redirects don't work.

@tanema
Copy link
Contributor

tanema commented Jan 16, 2020

@netwire88 Please open an issue.

@tanema tanema deleted the same_site_none branch January 21, 2020 17:25
@RichardBlair
Copy link
Contributor

@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. 👏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants