-
-
Notifications
You must be signed in to change notification settings - Fork 840
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
[Breaking] Samesite Cookie Fix #8269
[Breaking] Samesite Cookie Fix #8269
Conversation
- In DEBUG mode, turn off entirely - Allow False value (note: *not* a string) - Force insecure cookie in DEBUG mode
✅ Deploy Preview for inventree-web-pui-preview canceled.
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #8269 +/- ##
==========================================
- Coverage 84.22% 84.22% -0.01%
==========================================
Files 1162 1162
Lines 52517 52519 +2
Branches 1894 1894
==========================================
Hits 44235 44235
- Misses 7812 7814 +2
Partials 470 470
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
💔 All backports failed
Manual backportTo create the backport manually run:
Questions ?Please refer to the Backport tool documentation and see the Github Action logs for details |
A previous PR which was well-intentioned to solve this issue has resulted in problems with session authentication.
PR #8262 changed the default value of
CSRF_COOKIE_SAMESITE
andSESSION_COOKIE_SAMESITE
fromNone (boolean value)
to'None'
(string value). This is in accordance with the django documentation which specifies that these values must be strings and notNone
:However, note that the boolean value
False
is allowed, which disables the cookie checks entirely.Our previous literal value
None
(disallowed) was resulting a boolean check to evaluate the same as if the value was set toFalse
(allowed):This means that (prior to this patch), the samesite cookie session was effectively set to
False
(disabled), and not'None'
- which has different implications in operation. However, this value was causing a downstream error in the allauth package.Changes
So, this PR makes the following adjustments:
False
boolean literal)'None'
toFalse
False
inDEBUG
mode (to aid in easy development)Breaking
This is considered a "breaking" change because any production installation which has the samesite set to
None
will now evaluate to'None'
instead ofFalse
- resulting in different behaviour.Users in this predicament should change the value of
INVENTREE_COOKIE_SAMESITE
fromNone
toFalse
to disable the checks.References
None
causes errors #8254