Logout and session
Victor Loureiro Lima
auth system is in fact invalidating my current session id cookie, but afterwards it sets a new session id cookie, why does it do that?
Basically on my systems, I want to differentiate user in two groups: Anonymous ( ones that doesnt have a valid session id cookie ), logged ones ( ones that have a valid session id cookie ). If django auth system keeps setting a new session after a logout, I would not be able to differentiate them properly.
Is my approach correct? Why does django.contrib.auth do that, sends me a new session id after I logged out? Is there a way for me to configure it to NOT send me a new session cookie, after I logout?
thanks in advance,
Victor Lima
David De La Harpe Golden
> auth system is in fact invalidating my current session id cookie, but
> afterwards it sets a new session id cookie, why does it do that?
>
Um. So that anonymous users of your site still have sessions? Django
supports "anonymous sessions", sessions and auth are different.
> Basically on my systems, I want to differentiate user in two groups:
> Anonymous ( ones that doesnt have a valid session id cookie ), logged ones (
> ones that have a valid session id cookie ).
That's just not the way that distinction is made. Seeing as sessions
may be anonymous and all. For your code, note that if request.user is a
logged in User, .is_authenticated() will be True and .is_anonymous()
will be False. OTO, if request.user is an AnonymousUser,
.is_anonymous() will be True and is_authenticated() will be False.
Victor Loureiro Lima
My website depends heavilly on the caching system, I'm using cache_page to cache my view ( using memcached backend ),
however I have the "Hello, <logged in user>" on top of every page when the user is logged, thus I cant just cache everything.
So I began experimenting with @vary_on_cookies decorator, which seems to solve my problem, I will be caching my views based on a computed hash of the available cookies on the client ( as a side note, I had to apply a patch to django, in order for it to ignore certain cookie name regexp's, so that my google analytics cookies are ignore when building the view cache key for example).
That solved my problem, using @vary_on_cookie on my views, now I solved my caching issues, however I noticed that whenever a user logs out, I recieve a new sessionid, thus if the user log's in I will create a cache for him, based on its session id. But when it logs off, instead of joining the other clients that dont have the sessionid, it will become another "cached instance", and I have to avoid that situation.
I would like to understand why does django sends me another cookie after I logout calling auth.logout ( request )? And how can I
disable that? Or maybe, someone can point to the right design pattern for this situation.
thanks,
Victor Lima
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
David De La Harpe Golden
> Okay, let me further explain my problem...
>
> My website depends heavilly on the caching system, I'm using cache_page to
> cache my view ( using memcached backend ),
> however I have the "Hello, <logged in user>" on top of every page when the
> user is logged, thus I cant just cache everything.
Well, there is (now) a mechanism in place for caching template fragments.
So I suppose you could cache everything but the hello... I haven't tried to use
caching in such fine-grained fashion though:
http://docs.djangoproject.com/en/dev/topics/cache/#template-fragment-caching
> as a side note, I had to apply a patch to
> django, in order for it to ignore certain cookie name regexp's
Dirty, but if you're already mangling the django cache code to vary
on a subset of cookies rather than the standardised behaviour of varying
on all cookies (since it's really varying on the "Cookie" HTTP header), you could
probably further mangle it to vary only on a custom cookie other than
the django session cookie. I don't think this is a good approach, just saying.
> That solved my problem, using @vary_on_cookie on my views, now I solved my
> caching issues, however I noticed that whenever a user logs out, I recieve a
> new sessionid, thus if the user log's in I will create a cache for him,
> based on its session id. But when it logs off, instead of joining the other
> clients that dont have the sessionid, it will become another "cached
> instance", and I have to avoid that situation.
How about clients that have a sessionid before login? you may be
assuming clients don't have a session cookie before they login? That
may wind up true in your case I guess, but n.b. don't think
that login creates sessions in general - it may "bless" an existing
anonymous session with data in it into ownership by the logger-in (except when the existing
session is already owned by someone logged in, then it is replaced for security).
http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/__init__.py#L65
This is a feature - consider user starting filling out a form anonymously, data
being stashed in the session, then user logs in to authorise doing
something (posting comment, say).
Victor Loureiro Lima
On Thu, Dec 17, 2009 at 03:54:02PM -0200, Victor Loureiro Lima wrote:Well, there is (now) a mechanism in place for caching template fragments.
> Okay, let me further explain my problem...
>
> My website depends heavilly on the caching system, I'm using cache_page to
> cache my view ( using memcached backend ),
> however I have the "Hello, <logged in user>" on top of every page when the
> user is logged, thus I cant just cache everything.
So I suppose you could cache everything but the hello... I haven't tried to use
caching in such fine-grained fashion though:
http://docs.djangoproject.com/en/dev/topics/cache/#template-fragment-caching
Well, template caching invalidates view cache right? Plus, my understanding of the template cache is that
it will hit my view, do all the DB stuff, but skip the template processing which takes a while to finish, is my understanding right?
Dirty, but if you're already mangling the django cache code to vary
> as a side note, I had to apply a patch to
> django, in order for it to ignore certain cookie name regexp's
on a subset of cookies rather than the standardised behaviour of varying
on all cookies (since it's really varying on the "Cookie" HTTP header), you could
probably further mangle it to vary only on a custom cookie other than
the django session cookie. I don't think this is a good approach, just saying.
Well, we use google analytics on all pages, and the analytics cookie changes very often, for the same user,
thus it would generate another cache just because analytics cookie changed, and thats not what I want, I want
one cache per session ID cookie, only... that why we followed that approach... And I know that patching django
sucks a lot, but we couldnt live with the 5 requests/second that the non-cached django app was doing under heavy load.
How about clients that have a sessionid before login?
> That solved my problem, using @vary_on_cookie on my views, now I solved my
> caching issues, however I noticed that whenever a user logs out, I recieve a
> new sessionid, thus if the user log's in I will create a cache for him,
> based on its session id. But when it logs off, instead of joining the other
> clients that dont have the sessionid, it will become another "cached
> instance", and I have to avoid that situation.
you may be assuming clients don't have a session cookie before they login?
Clients that never logged in will not have the session ID cookie. Clients that have
logged in, will have the session ID cookie set for the web-browser session ( cookie is
set to exist while the browser is opened ).
That may wind up true in your case I guess, but n.b. don't think
that login creates sessions in general - it may "bless" an existing
anonymous session with data in it into ownership by the logger-in (except when the existing
session is already owned by someone logged in, then it is replaced for security).
http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/__init__.py#L65
This is a feature - consider user starting filling out a form anonymously, data
being stashed in the session, then user logs in to authorise doing
something (posting comment, say).
yes, in that case that would really be a problem... Maybe we could circunvent using our navigation scheme
to avoid that scenario, but that would really be a bust in our designs...
In your opinion, what would be the correct approach? Cache the views objects instead of the view it self, and cache
some of the templating? That would avoid the vary_on_cookie and would had a more granular effect on the system.
Atenciosamente,
Victor Lima
David De La Harpe Golden
> Well, template caching invalidates view cache right? Plus, my understanding
> of the template cache is that
> it will hit my view, do all the DB stuff, but skip the template processing
> which takes a while to finish, is my understanding right?
>
re "all the DB stuff": Depends what your view code is doing, but bear in mind
QuerySets are lazy, so it may allow skipping the heavy bit where a QuerySet
is actually forced to produce any results and thus be more of a win than you
might think.
> In your opinion, what would be the correct approach? Cache the views objects
> instead of the view it self, and cache
> some of the templating? That would avoid the vary_on_cookie and would had a
> more granular effect on the system.
>
I'm not sure, remember I haven't really used such fine-grained caching, but
I think the _template_ level caching should still operate for logged-in
users when CACHE_MIDDLEWARE_ANONYMOUS_ONLY is true, since the
CACHE_MIDDLEWARE_ANONYMOUS_ONLY settings is controlling, well, the
middleware (request-response wrapping) caching.
So you could use fine-grained template fragment caching for logged-in users, and
CACHE_MIDDLEWARE_ANONYMOUS_ONLY would still coarse-grain cache the non-logged-in ones
(regardless of existing session cookie as it's using request.user.is_authenticated() )