SessionMiddleware creates warnings on modern browsers if used on an endpoint for a site hosted in another site's iframe #2441
Replies: 1 comment
-
I imagine there's going to be lot of specific use cases and differences, I don't think the middleware is intended to take away all of the responsibility for insuring cookies are configured appropriately. For example there's currently no validating that the connection is over https when setting https_only=True. Using __Host- or __Secure- is in my opinion trivial, the author sets session_cookie="__Host-session" for example, and make sure they set https_only=True, do you think adding a argument like partitioned=True solve this? Documentation can be added as appropriate with a link to Mozilla's Set-Cookie Reference for guidance. I already have a pull request ready to submit with a change for #2019 complete with documentation based on @maartenbreddels suggestion with a couple tweaks and some from my original Pull I retracted. It also updated tests and documentation. Adding a partitioned argument to the pull request would be quick assuming It's not too many changes at once for the maintainers to accept. So for example the change could include a partitioned argument, app.add_middleware(SessionMiddleware, https_only=True, same_site="none",
partitioned=True, session_cookie="__Host-session",
secret_key="ARelatively!LargeComplicatedSecretFor@HMACEfficacy&") Which would result in a cookie:
Side note for others interested, I suspect this CHIPS change also affected CSP headers as well regarding iFrames and enforcement requiring more verbose policies. |
Beta Was this translation helpful? Give feedback.
-
I was using SessionMiddleware in an endpoint for a site whose page was embedded in an iframe and after a few attempts to get the parameters right (I realised I need to set same_site to "none" I got it to work - but Chrome (I'm currently using version 20) was still spamming warnings at me saying this approach would soon be blocked by third party cookie restrictions in the future and referring me to this help page.
For my use case the CHIPS/partitioned cookies seemed to be the right approach as the domain for the parent iframe was fixed - but that's where I ran into an issue with SessionMiddleware because I couldn't specify the Partitioned security option needed to enable CHIPS.
I'm currently using Starlette 0.35.1 - although I believe this is still an issue on current master branch.
The main issue is not being able to pass the "partitioned" parameter to the Set-Cookie call.
Some secondary minor issues are the same_site = "none" value actually constrains several other set cookie parameter values that SessionMiddleware doesn't enforce, namely:
To work around these problems I created my own copy of SessionMiddleware to use for now (although I'd love to go back to using the Starlette implementation if this can be resolved here). The last 5 lines of the dunder init are the main changes.
Note in this implementation I didn't add any logic to enforce the __Host- cookie name prefix or block the path from being changed. I just relied on the calling code to set that properly. With this new implementation and keeping the cookie name and path valid I was able to get (this version of) SessionMiddleware to work for a site in an iframe without triggering any warnings in Chrome.
Beta Was this translation helpful? Give feedback.
All reactions