Re: never_cache doesn't work for login page

2009-07-21 Thread Ronghui Yu 
Eugene Mirotin ??:
> May be the order of middleware classes does matter here?
>
> On Jul 19, 4:08 pm, Ronghui Yu  wrote:
>   
>> 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  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 
 
>> --
>> Ronghui Yu 
>> 
I had tried to reorder the middlewares, but it didn't work either.
Here is the comment of ConditionalGetMiddleware:

  5 Handles conditional GET operations. If the response has a ETag or
  6 Last-Modified header, and the request has If-None-Match or
  7 If-Modified-Since, the response is replaced by an HttpNotModified.
  8
  9 Also sets the Date and Content-Length response-headers.

I think the login page falls into this scope even it is decorated by 
never_cache.

-- 
Ronghui Yu 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: never_cache doesn't work for login page

2009-07-20 Thread Michael 
On Sun, Jul 19, 2009 at 9:08 AM, Ronghui Yu  wrote:

>  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.
>

I think you found a bug in the ConditionalGetMiddleware or the log in page.
The content on the page changes due to the token being updated on every
reload, so something is wrong there. I would file a ticket in the tracker
and post it here. As I said, I have experienced this, and my users find it
annoying, so I would like to spend a little more time on it and will try to
create a patch when I get a few seconds.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: never_cache doesn't work for login page

2009-07-20 Thread Eugene Mirotin 

May be the order of middleware classes does matter here?

On Jul 19, 4:08 pm, Ronghui Yu  wrote:
> 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  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 
>
> --
> Ronghui Yu 
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: never_cache doesn't work for login page

2009-07-19 Thread Ronghui Yu 
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  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 
>> 
> >
>
>   

-- 
Ronghui Yu 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: never_cache doesn't work for login page

2009-07-19 Thread Ronghui Yu 
That's a good idea. I'll make it the last resort if I can't figure out a 
better way to handle it.
Thank you

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  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 
>> 
> >
>
>   

-- 
Ronghui Yu 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: never_cache doesn't work for login page

2009-07-19 Thread Ronghui Yu 


Michael 写道:
> On Fri, Jul 17, 2009 at 11:19 AM, Ronghui Yu  > wrote:
>
>
>
> Michael 写道:
>> 2009/7/17 Ronghui Yu >
>>
>> 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 
>>
>>
>> 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 
>
>
> 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 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: never_cache doesn't work for login page

2009-07-18 Thread 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  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 
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: never_cache doesn't work for login page

2009-07-17 Thread Michael 
On Fri, Jul 17, 2009 at 11:19 AM, Ronghui Yu  wrote:

>
>
> Michael 写道:
>
> 2009/7/17 Ronghui Yu 
>
>> 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 
>>
>
> 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 
>

Hmm, interesting, What do your HTTP headers look like?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: never_cache doesn't work for login page

2009-07-17 Thread Ronghui Yu 


Michael ??:
> 2009/7/17 Ronghui Yu >
>
> 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 
>
>
> 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 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: never_cache doesn't work for login page

2009-07-17 Thread Michael 
2009/7/17 Ronghui Yu 

>  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 
>

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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---