I was not aware of that kind of attack. It's pretty clever. Thanks for the info and the workaround JS.
On Wednesday, July 1, 2015 at 4:29:32 PM UTC-7, Collin Anderson wrote: > > Hi, > > This is the best reason I could find: > > http://security.stackexchange.com/questions/62769/must-login-and-logout-action-have-csrf-protection > > One thing that's going on here is that the csrftoken changes every time > someone logs in, so the old login page now has a stale token. The changing > csrf token has bitten me a bunch of times. I've gotten around it by using > javascript to correct the token when submitting the form. > > $(document).on('submit', 'form[method=post]', function() { > $(this.csrfmiddlewaretoken).val(document.cookie.match( > 'csrftoken=([a-zA-Z0-9]{32})')[1]) > }) > > Collin > > On Wednesday, July 1, 2015 at 7:13:42 PM UTC-4, [email protected] wrote: >> >> Is there a reason django.contrib.auth.views.login should be decorated >> with csrf_protect? It results in annoying behavior, in the following >> scenario: >> >> In a browser window (Window1), go to the login page. >> In another browser window (Window2), go to the login page, and actually >> login, then logout. >> Back in Window1, fill in your credentials, and try to login. You get a >> 403. >> >> It seems like django.contrib.auth.views.login should be decorated with >> csrf_exempt instead. Are there any major security implications? >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e8a54634-a08b-4dbd-8df9-d5e1c7ab4b4f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
