Yusuf, did you use CSRF_COOKIE_SECURE = True and access the website using http instead of https?
https://stackoverflow.com/questions/17716624/django-csrf-cookie-not-set On Wed, May 22, 2019 at 6:18 PM Yusuf Musleh <[email protected]> wrote: > Hello Aldian, > > Thank you for your reply. > > That was one of the very first things we investigated, but it does not > seem to be the case, as the error happens sometimes when the page/form is > still fresh, in addition to that, the error message would have been > different if the token in the form expired, you'd get "CSRF token missing > or incorrect.". > > I want to mention that it's also not the case where a user is using > multiple tabs and logs out one of them and then submits a form in another > tab, those are legitimate errors that should happen, but we are witnessing > cases where a user opens the website (sometimes for their first time), > tries to submit a form, and they are not able to because it errors out with > "CSRF cookie not set." > > On Wednesday, May 22, 2019 at 2:31:43 AM UTC+3, Aldian Fazrihady wrote: >> >> The form page itself can expire if you let it readily opened in a browser >> tab for hours. If I did that and I didn't reload my form before using it, >> I will get a CSRF error. >> >> There several ideas to fix it. The point is to have CSRF cookie to >> always fresh, and your form will use that cookie instead of CSRF in hidden >> form field. >> >> Regards, >> >> Aldian Fazrihady >> https://www.aldianfazrihady.com/en-us/ >> >> On Wed, 22 May 2019, 04:52 Yusuf Musleh, <[email protected]> wrote: >> >>> Hello, >>> >>> We recently migrated from django 1.11.5 to 2.1.4. We performed all the >>> necessary changes needed for the migration and the application to work, >>> things went smoothly except for some CSRF validation issues. After the >>> migration on our production server we noticed an increase in the number of >>> 403 errors mainly the `CSRF cookie not set.` error. We added more logging >>> and investigated to see if they were legitimate errors, some are, however >>> we discovered that most aren’t. They were normal users making normal >>> requests on our website. We get around 30 of these failed requests that >>> should not have failed a day, it happens randomly across random devices, >>> browsers and urls, and has been quite difficult to reproduce. >>> >>> We Copy/Pasted the source code of `middleware.csrf` and added it to our >>> code base as a custom middleware to add more logging and get a better >>> traceback in sentry when the error occurs: >>> >>> - For some reason the token is not set. `csrf_token = >>> request.META.get('CSRF_COOKIE’)` returns `None` >>> >>> - We know that if a user got the error, if they simply refresh the page >>> things would work perfectly fine, this means that setting the token works, >>> but sometimes it does not >>> >>> - We know that it is not a problem with our frontend since we also got >>> this error in the django admin including non-login requests >>> >>> We also tried clearing all the expired sessions, and set >>> `CSRF_USE_SESSIONS = True`, however nothing changed. >>> >>> Also something that might be related, after the migration to 2.1 we >>> started noticing users getting logged out more frequently, with no errors >>> at all, although we set the session to expire in 30 days. We’ve had users >>> complain about occasionally being logged out multiple times in day, again >>> on random devices and browsers. >>> >>> Our project is deployed on AWS Elasticbeanstalk running Apache with RDS >>> PostgreSQL 9.6 and CloudFlare DNS/CDN/Cacheing setup. >>> >>> We’d appreciate any help or pointers regarding this issue or anywhere we >>> can look at that could be helpful. >>> >>> Thanks, >>> >>> Yusuf >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/django-users. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-users/06231250-3688-4323-8b79-7ebf2b66b449%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-users/06231250-3688-4323-8b79-7ebf2b66b449%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/a4593fc8-94a5-495d-8282-affbe957ea5e%40googlegroups.com > <https://groups.google.com/d/msgid/django-users/a4593fc8-94a5-495d-8282-affbe957ea5e%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAN7EoAb3v8dC5GPurZ-b5fVUbQVpM-%3DaR7Azo9HQDgS9U6X_pA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
