Michael 写道: > On Fri, Jul 17, 2009 at 11:19 AM, Ronghui Yu <[email protected] > <mailto:[email protected]>> wrote: > > > > Michael 写道: >> 2009/7/17 Ronghui Yu <[email protected] <mailto:[email protected]>> >> >> 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]> >> >> >> I have encountered this, but it isn't a problem with the admin, >> it is a problem with the browser. These pages are stored for >> offline use and then when the user goes to the page, they don't >> get a new token. You can see here [1] and here [2] where the >> views are cached. You can look at your browser and see that the >> headers are right as well. You should see something along these >> lines in the headers: Cache-Control max-age=0 >> >> 1] >> >> http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/sites.py#L324 >> 2] >> http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/sites.py#L188 >> >> I haven't been able to figure out how to fix this behavior in the >> browser, but the user only needs to refresh a few times to break >> that cache. >> >> I would love to hear if anyone else has figured something out to >> fix this. >> >> Also if you are using the 1.1 branch, make sure you update svn >> there was a recent fix put in for caching of all pages[3], but >> otherwise, the best I can tell, this is a browser issue, and not >> something Django can easily fix. >> >> 3] http://code.djangoproject.com/ticket/11416 >> >> I hope that helps, >> >> Michael >> >> > Thanks Michael. > > Look into the apache log, I see that when the login page is > accessed again, it returns 304, then the subsequent submit returns > 403. > > 116.22.69.90 - - [17/Jul/2009:23:12:06 +0800] "GET > /accounts/login/ HTTP/1.0" 304 > 116.22.69.90 - - [17/Jul/2009:23:12:17 +0800] "POST > /accounts/login/ HTTP/1.0" 403 159 > > I guess there are some tags that apache or mod_python omits. But I > am not sure. I will do more research soon. > > > -- > Ronghui Yu <mailto:[email protected]> > > > Hmm, interesting, What do your HTTP headers look like? >
I couldn't find a way to view all request headers in access log. How did you do that, Michael? Or you have another way? I would try to get it by setting DEBUG=True, but when it is set, login page always works fine. -- 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 -~----------~----~----~----~------~----~------~--~---
