| Subject: | Premature Expiry |
The session sets and "expires" store entry every request to extended the
session, but the "session" entry is only updated when modified.
If the store has its own expiry and the "session" is not written to
often (say only upon first login but not every request) then the session
may be prematurely lost.
This is not very apparent if the session expires setting is large enough
such that in that amount of time the session data would be updated (or
no user would use the application that long). But, if the time is small
enough (say to force a log out for inactivity after only a few minutes)
then users will be dropped.
See: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/#01986
I assume the reason for a separate "expires" store entry is to avoid the
need to save the session every request (because it's more data??). Or
that it was assumed that any store would NOT have its one expiry
mechanism that would expire the "session" store entry.
I'm not sure it needs a separate "expires" store.
Perhaps the expires value should be set very large and the application
would use a much shorter value inside the session and have its own code
for deleting the session. But, again, would not need a separate
"expires" store entry.
Another approach would be a large value for the "session" and a shorter
expires value for the "expires" store entry. But, that's more of a hack
than a solution.