-
Notifications
You must be signed in to change notification settings - Fork 169
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
session cookie not sent #497
Comments
I had this same issue with coldfront! When diagnosing the problem, I was catching http requests. It gets the code and state that is used to get the access token. so if you get the code and state, you can paste it into the url like: I've messaged the coldfront team on slack about this as well. I thought it was an ssl issue for a while. Thanks for posting this. |
Got the same issue, found this issue on another project. pennersr/django-allauth#3232 That leads to this https://stackoverflow.com/questions/42216700/how-can-i-redirect-after-oauth2-with-samesite-strict-and-still-get-my-cookies and a proposed solution:
|
Ideally we set this to Strict, but the session cookie is now not sent during redirects from OIDC providers (like Google, Azure, Keycloak) after succesful authentication, causing crashes on our end because we don't have access to the OIDC state and therefore we have a broken reference to the OIDC config model being used. See mozilla/mozilla-django-oidc#497 for more information - in summary the best solution would be to set it to Strict, but temporarily reduce this to Lax during the OIDC flow (possibly via middleware), which will require overriding some django.contrib.sessions middleware.
Ideally we set this to Strict, but the session cookie is now not sent during redirects from OIDC providers (like Google, Azure, Keycloak) after succesful authentication, causing crashes on our end because we don't have access to the OIDC state and therefore we have a broken reference to the OIDC config model being used. See mozilla/mozilla-django-oidc#497 for more information - in summary the best solution would be to set it to Strict, but temporarily reduce this to Lax during the OIDC flow (possibly via middleware), which will require overriding some django.contrib.sessions middleware.
Hi,
I don't know if this is really a mozzila-djano-oidc issue, or an django issue, but I've just been configuring an RP for google OIDC. I found that my client (chromium and firefox) were not transmitting the django sessionid cookie to the callback url because it has SameSite=Strict (and the calling url was google.com). The result was the mozilla-django-oidc couldn't get the oidc_claims from the session.
I "fixed" the problem by setting SESSION_COOKIE_SAMESITE='Lax' in config/auth.py so that the sessionid was transmitted.
I wonder whether
a) anyone else has experienced this
b) I'm doing something hideously wrong and that's why no one else seems to have hit this problem
For context I'm actually using an application called coldfront which is subclassing OIDCAuthenticationBackend,
I'm on django 3.2.17 and mozilla-django-oidc 3.0.0 and chromium 114.0.5735.106 with a google OIDC provider. I suspect this will affect anyone using mozilla-django-oidc where the OIDC Provider and RP are not on the same domain (eg using google for the provider for an RP on your own domain)
Thanks for you time ;-)
The text was updated successfully, but these errors were encountered: