Problem with clearsession admin command and file based sessions

[Douglas Fraser]

Hi,

  The website I deal with uses file based sessions, and there is no logging in of users or anything like that.  Most of the time, no data is put into the session, and the session expiry time is not explicitly set in the code.  I've set SESSION_COOKIE_AGE to 48 hours, and so I'd expect the session files to be deleted after 48 hours.

But "clearsessions" is not causing the old sessions to be deleted, and so I'm wondering if I overlooked something I should have implemented in the code etc. Should session.set_expiry always be explicitly called?  SESSION_EXPIRE_AT_BROWSER_CLOSE is True, so I expected SESSION_COOKIE_AGE to act as the determining factor when session files would get deleted (when 'clearsessions' gets called)

But looking at the code for the admin 'clearsessions' command (base.py and file.py) and the code related to file based sessions, it seems SESSION_COOKIE_AGE will always get returned from get_expiry_age in this situation, and thus the check to see if the expiry_age is negative always fails, and so the file is never deleted

My gut says load() in django/contrib/sessions/backend/file.py needs to be a little more sophisticated in determining the actual age of the file relative to what is returned from get_expiry_age.

Or am I just wrong in assuming sessions ought to be cleaned up automatically in this case?

thanks
Doug

[Douglas Fraser]

update: from the docs:

set_expiry(value)

• If value is None, the session reverts to using the global session expiry policy.

Reading a session is not considered activity for expiration purposes. Session expiration is computed from the last time the session was modified.

 get_expiry_age()

Returns the number of seconds until this session expires. For sessions with no custom expiration (or those set to expire at browser close), this will equal SESSION_COOKIE_AGE.

from these, I was led to believe SESSION_COOKIE_AGE determines when a session has expired, if the expiry is None

Doug

[Tom Evans]

I read that differently, sessions with no custom expiration or those
set to expire at browser close will always return SESSION_COOKIE_AGE -
because the session is only "expired" when the browser has forgotten
the session ID, not when N seconds has passed.

Cheers

Tom

[Douglas Fraser]

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