well, yes, I see that. But anything relying upon get_expiry_age returning the actual number of seconds left (like in the clearsessions logic) rather than a constant all the time is going to fail in this scenario. If SESSION_EXPIRES_AT_BROWSER_CLOSE is True, that is the global expiry policy (in my mind) but then how does the system detect the session has expired if the person never visits the website again? Thus 'clearsessions' never does actually delete the session files. So having SESSION_EXPIRES... = True and expiry = None means session files will be kept forever and 'clearsessions' won't clean them up, if set_expiry is not being explicitly called.
This is sort of like all the questions I've seen about database sessions and 2.4GB of them and ... There is something wrong here, but for me to spend any more time figuring it out versus just setting an explicit expire time to force the issue is wasteful. Or use a memory cache....
doug
-- This is sort of like all the questions I've seen about database sessions and 2.4GB of them and ... There is something wrong here, but for me to spend any more time figuring it out versus just setting an explicit expire time to force the issue is wasteful. Or use a memory cache....
doug
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/fd31e26c-b6af-49e1-970a-3e7c97aa7cac%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment