It proves that it is introduced by django.middleware.http.ConditionalGetMiddleware. It returns 304 when requesting the same login page, so at last the browser uses the former one. It works fine after removing this middleware. I believe this middleware cannot work with never_cache.
Eugene Mirotin ??: > Isn't adding a timestamp to the url a workaround? > I mean making all links to /login/ look like /login/?_=timestamp > This can be easily done on the client side with some JS library, or, > on the server side. > > Not nice, but it should help, I guess. > > On Jul 17, 5:24 pm, Ronghui Yu <[email protected]> wrote: > >> Hi, All, >> >> I have a project that have CsrfMiddleware enable, all forms work fine, >> but the login form doesn't, for all browsers(IE,Chrome,Firefox,Safari). >> Most of the time, it throws 403, which is thrown by CsrfMiddleware. >> That's because the browser cache the login page, so each time the login >> page is opened, the csrfmiddlearetoken value doesn't get update. If the >> browser cache is cleaned before opening the login page, then it works >> fine. But this is not what I expect. >> >> When look into django.contrib.auth.views, the login view is decorated by >> never_cache, but actually it doesn't work for me. I have no idea what's >> wrong with it. Has anybody ever encounted this situation? Or could >> anybody give me some hints? >> >> Thanks in advance. >> >> -- >> Ronghui Yu <mailto:[email protected]> >> > > > > -- Ronghui Yu <mailto:[email protected]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
