[Catalyst] Session Expiry

[Bill Moseley]

On Sat, Mar 01, 2008 at 09:50:10PM -0600, Jonathan Rockway wrote:
> * On Sat, Mar 01 2008, Bill Moseley wrote:
> > Is it expected that the application update the session every request
> > to prevent expiry while a user is actively using the application?
> 
> Is the problem that $c->session->{__expires} doesn't get updated, or is
> the problem that the Cache backend is losing things due to its expiry
> not being updated?

Well, I think it's both, althogh I'm not sure __expires is used any
more.

> In the second case, it's just a bug in the Session::Store::Cache store
> that can be fixed with the addition of a backend_expires configuration
> key, probably set to "never" by default.  It's annoying to have two
> expiration times, but that can be easily worked around.  (Set cache
> expiration every time you update __expires, or just set it to 2038 and
> hope Catalyst expires it for you.)

Session::Store::Cache is a pretty thin layer so I'm not sure it's that
plugin's problem.  It overrides "store_session_data" and the session
plugin uses that to store both the "expires" and "session" (and flash)
entities. So they all get the same expire time.

Maybe if the Session::Store::Cache plugin overrode
_save_session_expires() and _save_session() so they could have
separate expires times that might work.  But, that's overriding
private methods and I'm not sure giving the "session" store a huge
expiry isn't more of a hack than a solution.

So, really, the problem is simply that the session plugin updates the
"expires" store every request and not the "session" store.  And if the
store has it's own expiry (like memcached) then if the "session" is
not updated it will expire before the updated-every-request "expires"
one will.  But, maybe the assumption was that the store would not have
its own expiry mechanism and it would all be handled by the Session
plugin.

What's the point of having a separate "expires" store that is updated
every request?  So that we save updating the "session" every request
because it's more data to write to the store?

As it turns out, it's actually more expensive since now I have to
force a session save in addition to the expires save every request.
So the use of a __expires entry in the session would be more
efficient.  (Not that it's a huge problem in the larger scope of the
request.)

If it's likely that an application might not update the session data
often (triggering a session store), and it's likely that the store
manages an expires time, then maybe the Session plugin should not use
Object::Signature to determine when to store the session, and rather
just update it every request.




-- 
Bill Moseley
moseley at hank.org