Re: caching and authentication
thanks for the answer. we _are_ doing a redirect on logout. On 16 Sep., 16:17, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 9/13/07, patrickk <[EMAIL PROTECTED]> wrote: > > > if 2 users are logged in, the username is displayed correctly for each > > user. BUT: if a user is logged-out, his/her username is still > > displayed. something doesn´t seem to work here and I can´t figure out > > what´s wrong. > > If a user logs out, the 'request.user' attribute is not updated > immediately; it will become an AnonymousUser instance on the *next* > request, not on the one in which the user is logging out. This is why > it's always a good idea to redirect after doing a logout, because that > "clears" request.user. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: caching and authentication
On 9/13/07, patrickk <[EMAIL PROTECTED]> wrote: > if 2 users are logged in, the username is displayed correctly for each > user. BUT: if a user is logged-out, his/her username is still > displayed. something doesn´t seem to work here and I can´t figure out > what´s wrong. If a user logs out, the 'request.user' attribute is not updated immediately; it will become an AnonymousUser instance on the *next* request, not on the one in which the user is logging out. This is why it's always a good idea to redirect after doing a logout, because that "clears" request.user. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: caching and authentication
does anyone have an idea? we should go online with our site tomorrow
and I don´t have a clue on how to solve this problem.
thanks,
patrick
On 13 Sep., 10:23, patrickk <[EMAIL PROTECTED]> wrote:
> one additional note:
> if 2 users are logged in, the username is displayed correctly for each
> user. BUT: if a user is logged-out, his/her username is still
> displayed. something doesn´t seem to work here and I can´t figure out
> what´s wrong.
>
> On 13 Sep., 10:14, patrickk <[EMAIL PROTECTED]> wrote:
>
> > I´ve upgraded to the current trunk and it´s still not working.
>
> > this is my views:
>
> > def top_imagegalleries(request):
> > ...
>
> > response = render_to_response('site/container/
> > topimagegalleries.html', {
> > 'object_list_left': rendered_object_list_left,
> > 'object_list_right': rendered_object_list_right,
> > 'category': 'filme',
> > 'subcategory': 'bildgalerien',
> > 'site_title': 'Bildgalerien',
> > 'title': 'Bildgalerien',
> > 'sidebar_list': rendered_sidebar_list,
> > 'limit': limit.limit,
> > }, context_instance=RequestContext(request) )
> > patch_vary_headers(response, ['Cookie'])
> > return response
> > top_imagegalleries = cache_page(top_imagegalleries, 60 * 15)
>
> > My username is still displayed on the page when I´m logged out.
> > For most of our pages, we use cached blocks within the site, but that
> > doesn´t work for all the pages we have. We have to cache some high-
> > traffic pages as a "whole" (still displaying the right username
> > though).
>
> > thanks,
> > patrick
>
> > On 29 Aug., 17:33, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
>
> > > It's clear to me that the docs involving patch_vary_header, cache_page
> > > and the cache middleware need to be improved.
>
> > > I'm using this thread as proof. :)
>
> > > The cache_page decorator is actually just a wrapper around the cache
> > > middleware; think of it as view-specific application ofthe cache
> > > middleware.
>
> > > In any case, thepatch_vary_headers*should* work with the cache_page
> > > decorator; the decorator forms the cache key based on the response.
> > > This is a separate problem from the unicode issue.
>
> > > Can you provide any info on what isn't working as expected with
> > > thepatch_vary_headerscall?
>
> > > On 8/29/07, patrickk <[EMAIL PROTECTED]> wrote:
>
> > > > I´ve been too optimistic - the above code doesn´t work.
> > > > (This wholecaching-issue gives me the willies)
>
> > > > On 29 Aug., 12:21, patrickk <[EMAIL PROTECTED]> wrote:
> > > > > it´s a bit late, but I just wanted to tell that it works with
> > > > >patch_vary_headers.
> > > > > in my opinion, this could be explained better in the docs.
>
> > > > > so, if one uses a page based on user-authenticationand wants to cache
> > > > > that page using the cache_page decorator, here´s the code:
>
> > > > > def my_view(request):
> > > > >
>
> > > > > response = render_to_response('site/whatever/template.html', {
> > > > > ...
> > > > > }, context_instance=RequestContext(request) )
> > > > >patch_vary_headers(response, ['Cookie'])
> > > > > return response
> > > > > my_view = cache_page(may_view, 60 * 15)
>
> > > > > thanks,
> > > > > patrick
>
> > > > > On 8 Jul., 01:18, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
>
> > > > > > On 7/7/07, patrick k. <[EMAIL PROTECTED]> wrote:
>
> > > > > > > I don´t understand why the page_cache is keyed by the vary header
> > > > > > > and
> > > > > > > the view_cache is not. is there a reason for this?
>
> > > > > > You mean cache_page rather than page_cache, but what is view_cache?
>
> > > > > > I think I may have spotted the problem: the cache_page decorator
> > > > > > runs
> > > > > > before the Vary header gets patched for the session access.
>
> > > > > > As a test, just before you return your HttpResponse, try adding this
> > > > > > to one of your auth views, and try to use the cache_page decorator:
>
> > > > > > from django.utils.cacheimportpatch_vary_headers
> > > > > >patch_vary_headers(response, ('Cookie',))
>
> > > > > > (Maye sure to dump yourcachefirst, too.)
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: caching and authentication
one additional note:
if 2 users are logged in, the username is displayed correctly for each
user. BUT: if a user is logged-out, his/her username is still
displayed. something doesn´t seem to work here and I can´t figure out
what´s wrong.
On 13 Sep., 10:14, patrickk <[EMAIL PROTECTED]> wrote:
> I´ve upgraded to the current trunk and it´s still not working.
>
> this is my views:
>
> def top_imagegalleries(request):
> ...
>
> response = render_to_response('site/container/
> topimagegalleries.html', {
> 'object_list_left': rendered_object_list_left,
> 'object_list_right': rendered_object_list_right,
> 'category': 'filme',
> 'subcategory': 'bildgalerien',
> 'site_title': 'Bildgalerien',
> 'title': 'Bildgalerien',
> 'sidebar_list': rendered_sidebar_list,
> 'limit': limit.limit,
> }, context_instance=RequestContext(request) )
> patch_vary_headers(response, ['Cookie'])
> return response
> top_imagegalleries = cache_page(top_imagegalleries, 60 * 15)
>
> My username is still displayed on the page when I´m logged out.
> For most of our pages, we use cached blocks within the site, but that
> doesn´t work for all the pages we have. We have to cache some high-
> traffic pages as a "whole" (still displaying the right username
> though).
>
> thanks,
> patrick
>
> On 29 Aug., 17:33, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
>
> > It's clear to me that the docs involving patch_vary_header, cache_page
> > and the cache middleware need to be improved.
>
> > I'm using this thread as proof. :)
>
> > The cache_page decorator is actually just a wrapper around the cache
> > middleware; think of it as view-specific application ofthe cache
> > middleware.
>
> > In any case, thepatch_vary_headers*should* work with the cache_page
> > decorator; the decorator forms the cache key based on the response.
> > This is a separate problem from the unicode issue.
>
> > Can you provide any info on what isn't working as expected with
> > thepatch_vary_headerscall?
>
> > On 8/29/07, patrickk <[EMAIL PROTECTED]> wrote:
>
> > > I´ve been too optimistic - the above code doesn´t work.
> > > (This whole caching-issue gives me the willies)
>
> > > On 29 Aug., 12:21, patrickk <[EMAIL PROTECTED]> wrote:
> > > > it´s a bit late, but I just wanted to tell that it works with
> > > >patch_vary_headers.
> > > > in my opinion, this could be explained better in the docs.
>
> > > > so, if one uses a page based on user-authentication and wants to cache
> > > > that page using the cache_page decorator, here´s the code:
>
> > > > def my_view(request):
> > > >
>
> > > > response = render_to_response('site/whatever/template.html', {
> > > > ...
> > > > }, context_instance=RequestContext(request) )
> > > >patch_vary_headers(response, ['Cookie'])
> > > > return response
> > > > my_view = cache_page(may_view, 60 * 15)
>
> > > > thanks,
> > > > patrick
>
> > > > On 8 Jul., 01:18, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
>
> > > > > On 7/7/07, patrick k. <[EMAIL PROTECTED]> wrote:
>
> > > > > > I don´t understand why the page_cache is keyed by the vary header
> > > > > > and
> > > > > > the view_cache is not. is there a reason for this?
>
> > > > > You mean cache_page rather than page_cache, but what is view_cache?
>
> > > > > I think I may have spotted the problem: the cache_page decorator runs
> > > > > before the Vary header gets patched for the session access.
>
> > > > > As a test, just before you return your HttpResponse, try adding this
> > > > > to one of your auth views, and try to use the cache_page decorator:
>
> > > > > from django.utils.cacheimportpatch_vary_headers
> > > > >patch_vary_headers(response, ('Cookie',))
>
> > > > > (Maye sure to dump yourcachefirst, too.)
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: caching and authentication
I´ve upgraded to the current trunk and it´s still not working.
this is my views:
def top_imagegalleries(request):
...
response = render_to_response('site/container/
topimagegalleries.html', {
'object_list_left': rendered_object_list_left,
'object_list_right': rendered_object_list_right,
'category': 'filme',
'subcategory': 'bildgalerien',
'site_title': 'Bildgalerien',
'title': 'Bildgalerien',
'sidebar_list': rendered_sidebar_list,
'limit': limit.limit,
}, context_instance=RequestContext(request) )
patch_vary_headers(response, ['Cookie'])
return response
top_imagegalleries = cache_page(top_imagegalleries, 60 * 15)
My username is still displayed on the page when I´m logged out.
For most of our pages, we use cached blocks within the site, but that
doesn´t work for all the pages we have. We have to cache some high-
traffic pages as a "whole" (still displaying the right username
though).
thanks,
patrick
On 29 Aug., 17:33, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> It's clear to me that the docs involving patch_vary_header, cache_page
> and the cache middleware need to be improved.
>
> I'm using this thread as proof. :)
>
> The cache_page decorator is actually just a wrapper around the cache
> middleware; think of it as view-specific application ofthe cache
> middleware.
>
> In any case, thepatch_vary_headers*should* work with the cache_page
> decorator; the decorator forms the cache key based on the response.
> This is a separate problem from the unicode issue.
>
> Can you provide any info on what isn't working as expected with
> thepatch_vary_headerscall?
>
> On 8/29/07, patrickk <[EMAIL PROTECTED]> wrote:
>
>
>
> > I´ve been too optimistic - the above code doesn´t work.
> > (This whole caching-issue gives me the willies)
>
> > On 29 Aug., 12:21, patrickk <[EMAIL PROTECTED]> wrote:
> > > it´s a bit late, but I just wanted to tell that it works with
> > >patch_vary_headers.
> > > in my opinion, this could be explained better in the docs.
>
> > > so, if one uses a page based on user-authentication and wants to cache
> > > that page using the cache_page decorator, here´s the code:
>
> > > def my_view(request):
> > >
>
> > > response = render_to_response('site/whatever/template.html', {
> > > ...
> > > }, context_instance=RequestContext(request) )
> > >patch_vary_headers(response, ['Cookie'])
> > > return response
> > > my_view = cache_page(may_view, 60 * 15)
>
> > > thanks,
> > > patrick
>
> > > On 8 Jul., 01:18, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
>
> > > > On 7/7/07, patrick k. <[EMAIL PROTECTED]> wrote:
>
> > > > > I don´t understand why the page_cache is keyed by the vary header and
> > > > > the view_cache is not. is there a reason for this?
>
> > > > You mean cache_page rather than page_cache, but what is view_cache?
>
> > > > I think I may have spotted the problem: the cache_page decorator runs
> > > > before the Vary header gets patched for the session access.
>
> > > > As a test, just before you return your HttpResponse, try adding this
> > > > to one of your auth views, and try to use the cache_page decorator:
>
> > > > from django.utils.cacheimportpatch_vary_headers
> > > >patch_vary_headers(response, ('Cookie',))
>
> > > > (Maye sure to dump yourcachefirst, too.)
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: caching and authentication
thanks jeremy.
answer to "what isn´t working":
on the top of each page, we have two links which depend on whether the
user is authenticated or not.
either: username / logout (if authenticated)
or: login / register (if not authenticated)
when I use cache_page (with or without patch_vary_headers resp.
vary_on_headers('Cookie')) my username is still displayed when I´m
logged out (and also the other way round).
patrick.
On 29 Aug., 17:33, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> It's clear to me that the docs involving patch_vary_header, cache_page
> and the cache middleware need to be improved.
>
> I'm using this thread as proof. :)
>
> The cache_page decorator is actually just a wrapper around the cache
> middleware; think of it as view-specific application ofthe cache
> middleware.
>
> In any case, the patch_vary_headers *should* work with the cache_page
> decorator; the decorator forms the cache key based on the response.
> This is a separate problem from the unicode issue.
>
> Can you provide any info on what isn't working as expected with the
> patch_vary_headers call?
>
> On 8/29/07, patrickk <[EMAIL PROTECTED]> wrote:
>
>
>
> > I´ve been too optimistic - the above code doesn´t work.
> > (This whole caching-issue gives me the willies)
>
> > On 29 Aug., 12:21, patrickk <[EMAIL PROTECTED]> wrote:
> > > it´s a bit late, but I just wanted to tell that it works with
> > > patch_vary_headers.
> > > in my opinion, this could be explained better in the docs.
>
> > > so, if one uses a page based on user-authentication and wants to cache
> > > that page using the cache_page decorator, here´s the code:
>
> > > def my_view(request):
> > >
>
> > > response = render_to_response('site/whatever/template.html', {
> > > ...
> > > }, context_instance=RequestContext(request) )
> > > patch_vary_headers(response, ['Cookie'])
> > > return response
> > > my_view = cache_page(may_view, 60 * 15)
>
> > > thanks,
> > > patrick
>
> > > On 8 Jul., 01:18, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
>
> > > > On 7/7/07, patrick k. <[EMAIL PROTECTED]> wrote:
>
> > > > > I don´t understand why the page_cache is keyed by the vary header and
> > > > > the view_cache is not. is there a reason for this?
>
> > > > You mean cache_page rather than page_cache, but what is view_cache?
>
> > > > I think I may have spotted the problem: the cache_page decorator runs
> > > > before the Vary header gets patched for the session access.
>
> > > > As a test, just before you return your HttpResponse, try adding this
> > > > to one of your auth views, and try to use the cache_page decorator:
>
> > > > from django.utils.cacheimport patch_vary_headers
> > > > patch_vary_headers(response, ('Cookie',))
>
> > > > (Maye sure to dump yourcachefirst, too.)
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: caching and authentication
It's clear to me that the docs involving patch_vary_header, cache_page
and the cache middleware need to be improved.
I'm using this thread as proof. :)
The cache_page decorator is actually just a wrapper around the cache
middleware; think of it as view-specific application ofthe cache
middleware.
In any case, the patch_vary_headers *should* work with the cache_page
decorator; the decorator forms the cache key based on the response.
This is a separate problem from the unicode issue.
Can you provide any info on what isn't working as expected with the
patch_vary_headers call?
On 8/29/07, patrickk <[EMAIL PROTECTED]> wrote:
>
> I´ve been too optimistic - the above code doesn´t work.
> (This whole caching-issue gives me the willies)
>
> On 29 Aug., 12:21, patrickk <[EMAIL PROTECTED]> wrote:
> > it´s a bit late, but I just wanted to tell that it works with
> > patch_vary_headers.
> > in my opinion, this could be explained better in the docs.
> >
> > so, if one uses a page based on user-authentication and wants to cache
> > that page using the cache_page decorator, here´s the code:
> >
> > def my_view(request):
> >
> >
> > response = render_to_response('site/whatever/template.html', {
> > ...
> > }, context_instance=RequestContext(request) )
> > patch_vary_headers(response, ['Cookie'])
> > return response
> > my_view = cache_page(may_view, 60 * 15)
> >
> > thanks,
> > patrick
> >
> > On 8 Jul., 01:18, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> >
> > > On 7/7/07, patrick k. <[EMAIL PROTECTED]> wrote:
> >
> > > > I don´t understand why the page_cache is keyed by the vary header and
> > > > the view_cache is not. is there a reason for this?
> >
> > > You mean cache_page rather than page_cache, but what is view_cache?
> >
> > > I think I may have spotted the problem: the cache_page decorator runs
> > > before the Vary header gets patched for the session access.
> >
> > > As a test, just before you return your HttpResponse, try adding this
> > > to one of your auth views, and try to use the cache_page decorator:
> >
> > > from django.utils.cacheimport patch_vary_headers
> > > patch_vary_headers(response, ('Cookie',))
> >
> > > (Maye sure to dump yourcachefirst, too.)
>
>
> >
>
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: caching and authentication
I´ve been too optimistic - the above code doesn´t work.
(This whole caching-issue gives me the willies)
On 29 Aug., 12:21, patrickk <[EMAIL PROTECTED]> wrote:
> it´s a bit late, but I just wanted to tell that it works with
> patch_vary_headers.
> in my opinion, this could be explained better in the docs.
>
> so, if one uses a page based on user-authentication and wants to cache
> that page using the cache_page decorator, here´s the code:
>
> def my_view(request):
>
>
> response = render_to_response('site/whatever/template.html', {
> ...
> }, context_instance=RequestContext(request) )
> patch_vary_headers(response, ['Cookie'])
> return response
> my_view = cache_page(may_view, 60 * 15)
>
> thanks,
> patrick
>
> On 8 Jul., 01:18, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
>
> > On 7/7/07, patrick k. <[EMAIL PROTECTED]> wrote:
>
> > > I don´t understand why the page_cache is keyed by the vary header and
> > > the view_cache is not. is there a reason for this?
>
> > You mean cache_page rather than page_cache, but what is view_cache?
>
> > I think I may have spotted the problem: the cache_page decorator runs
> > before the Vary header gets patched for the session access.
>
> > As a test, just before you return your HttpResponse, try adding this
> > to one of your auth views, and try to use the cache_page decorator:
>
> > from django.utils.cacheimport patch_vary_headers
> > patch_vary_headers(response, ('Cookie',))
>
> > (Maye sure to dump yourcachefirst, too.)
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: caching and authentication
it´s a bit late, but I just wanted to tell that it works with
patch_vary_headers.
in my opinion, this could be explained better in the docs.
so, if one uses a page based on user-authentication and wants to cache
that page using the cache_page decorator, here´s the code:
def my_view(request):
response = render_to_response('site/whatever/template.html', {
...
}, context_instance=RequestContext(request) )
patch_vary_headers(response, ['Cookie'])
return response
my_view = cache_page(may_view, 60 * 15)
thanks,
patrick
On 8 Jul., 01:18, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> On 7/7/07, patrick k. <[EMAIL PROTECTED]> wrote:
>
> > I don´t understand why the page_cache is keyed by the vary header and
> > the view_cache is not. is there a reason for this?
>
> You mean cache_page rather than page_cache, but what is view_cache?
>
> I think I may have spotted the problem: the cache_page decorator runs
> before the Vary header gets patched for the session access.
>
> As a test, just before you return your HttpResponse, try adding this
> to one of your auth views, and try to use the cache_page decorator:
>
> from django.utils.cacheimport patch_vary_headers
> patch_vary_headers(response, ('Cookie',))
>
> (Maye sure to dump yourcachefirst, too.)
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: caching and authentication
On 7/7/07, patrick k. <[EMAIL PROTECTED]> wrote:
> I don´t understand why the page_cache is keyed by the vary header and
> the view_cache is not. is there a reason for this?
You mean cache_page rather than page_cache, but what is view_cache?
I think I may have spotted the problem: the cache_page decorator runs
before the Vary header gets patched for the session access.
As a test, just before you return your HttpResponse, try adding this
to one of your auth views, and try to use the cache_page decorator:
from django.utils.cache import patch_vary_headers
patch_vary_headers(response, ('Cookie',))
(Maye sure to dump your cache first, too.)
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: caching and authentication
Am 07.07.2007 um 19:36 schrieb Honza Král: > On 7/7/07, patrick k. <[EMAIL PROTECTED]> wrote: >> >> >> Am 07.07.2007 um 02:13 schrieb Jeremy Dunck: >> >>> >>> On 7/6/07, patrickk <[EMAIL PROTECTED]> wrote: when having a header where the username and a logout-button is displayed, how do you cache this page/view? >>> >>> There's a CACHE_MIDDLEWARE_ANONYMOUS_ONLY setting if you want to >>> only >>> do anonymous caching. >>> >>> But I think you must have your cache middleware in the wrong >>> order if >>> you're seeing this problem. >> >> I�m not using the cache middleware. >> >>> >>> page_cache and the cache middleware both are keyed by the Vary >>> header, >>> and the Vary header will contain 'Cookie' if you've accessed the >>> session object-- which you must have done if you have the >>> request.user >>> in your template. >> >> I�m currently using the per-view cache (well, actually I�m >> using the >> low-level cache because of the mentioned problems). >> >> I�d like to cache individual views - the only thing changing is the >> header (either "username/logout" or "login/register"), everything >> else is the same. > > if its that case, you could write your own middleware that would > rewrite the page - just put some placeholder where this information is > supposed to go, and let the middleware handle it I have to check that ... currently, I´ve no idea how this could be done (but I guess the docs will tell me). > > OR > > do not cache the entire page, but rather some reusable blocks or > data... that was the initial question. when caching part of the page, I have to render the templates twice. first render the cached part and then the dynamic part. this leads to strange templates though (because I´m caching the whole page except for one line of code). I don´t understand why the page_cache is keyed by the vary header and the view_cache is not. is there a reason for this? thanks, patrick > >> >> thanks, >> patrick >> >> >>> >>> Please post your MIDDLEWARE_CLASSES tuple. >>> is this (using the low-level cache) the best way doing this? >>> >>> I'm not convinced you need it. >>> >> >> >>> >> > > > -- > Honza Kr�l > E-Mail: [EMAIL PROTECTED] > ICQ#: 107471613 > Phone: +420 606 678585 > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: caching and authentication
On 7/7/07, patrick k. <[EMAIL PROTECTED]> wrote: > > > Am 07.07.2007 um 02:13 schrieb Jeremy Dunck: > > > > > On 7/6/07, patrickk <[EMAIL PROTECTED]> wrote: > >> > >> when having a header where the username and a logout-button is > >> displayed, how do you cache this page/view? > > > > There's a CACHE_MIDDLEWARE_ANONYMOUS_ONLY setting if you want to only > > do anonymous caching. > > > > But I think you must have your cache middleware in the wrong order if > > you're seeing this problem. > > I�m not using the cache middleware. > > > > > page_cache and the cache middleware both are keyed by the Vary header, > > and the Vary header will contain 'Cookie' if you've accessed the > > session object-- which you must have done if you have the request.user > > in your template. > > I�m currently using the per-view cache (well, actually I�m using the > low-level cache because of the mentioned problems). > > I�d like to cache individual views - the only thing changing is the > header (either "username/logout" or "login/register"), everything > else is the same. if its that case, you could write your own middleware that would rewrite the page - just put some placeholder where this information is supposed to go, and let the middleware handle it OR do not cache the entire page, but rather some reusable blocks or data... > > thanks, > patrick > > > > > > Please post your MIDDLEWARE_CLASSES tuple. > > > >> is this (using the low-level cache) the best way doing this? > >> > > > > I'm not convinced you need it. > > > > > > > > > > -- Honza Kr�l E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: caching and authentication
Am 07.07.2007 um 02:13 schrieb Jeremy Dunck: > > On 7/6/07, patrickk <[EMAIL PROTECTED]> wrote: >> >> when having a header where the username and a logout-button is >> displayed, how do you cache this page/view? > > There's a CACHE_MIDDLEWARE_ANONYMOUS_ONLY setting if you want to only > do anonymous caching. > > But I think you must have your cache middleware in the wrong order if > you're seeing this problem. I´m not using the cache middleware. > > page_cache and the cache middleware both are keyed by the Vary header, > and the Vary header will contain 'Cookie' if you've accessed the > session object-- which you must have done if you have the request.user > in your template. I´m currently using the per-view cache (well, actually I´m using the low-level cache because of the mentioned problems). I´d like to cache individual views - the only thing changing is the header (either "username/logout" or "login/register"), everything else is the same. thanks, patrick > > Please post your MIDDLEWARE_CLASSES tuple. > >> is this (using the low-level cache) the best way doing this? >> > > I'm not convinced you need it. > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: caching and authentication
On 7/6/07, patrickk <[EMAIL PROTECTED]> wrote: > > when having a header where the username and a logout-button is > displayed, how do you cache this page/view? There's a CACHE_MIDDLEWARE_ANONYMOUS_ONLY setting if you want to only do anonymous caching. But I think you must have your cache middleware in the wrong order if you're seeing this problem. page_cache and the cache middleware both are keyed by the Vary header, and the Vary header will contain 'Cookie' if you've accessed the session object-- which you must have done if you have the request.user in your template. Please post your MIDDLEWARE_CLASSES tuple. > is this (using the low-level cache) the best way doing this? > I'm not convinced you need it. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: caching and authentication
Yes. However, you can probably cut down on your code in the view a bit by saying if the user is authenticated, then don't add it to the cache. If they are not authenticated, cache the result. This should allow you to render the template once, then conditionally cache the result after rendering. On Jul 6, 5:40 am, patrickk <[EMAIL PROTECTED]> wrote: > when having a header where the username and a logout-button is > displayed, how do you cache this page/view? > > when using the per-view cache, the authentication doesn´t work > anymore (that means that my username is still displayed in the > header, although I´m already logged out). > when using the low-level cache it works, but we have to split the > templates: > - first render (and cache) the site without the header > - then render the cached template with the header > > is this (using the low-level cache) the best way doing this? > > thanks, > patrick --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
caching and authentication
when having a header where the username and a logout-button is displayed, how do you cache this page/view? when using the per-view cache, the authentication doesn´t work anymore (that means that my username is still displayed in the header, although I´m already logged out). when using the low-level cache it works, but we have to split the templates: - first render (and cache) the site without the header - then render the cached template with the header is this (using the low-level cache) the best way doing this? thanks, patrick --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
