[Tickets #12136] Re: Session Timeout not enforced

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12136
------------------------------------------------------------------------------
  Ticket             | 12136
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Session Timeout not enforced
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2013-05-02 11:27) wrote:

> I can't tell about the cost of storing the session if not necessary,  
> but Michael has put a lot of work into only writing to the session  
> if really necessary, so I trust him that there are very good reason  
> to not write to the session on every request.

Many years ago, I was retained by a large company that wanted to  
further adapt Horde (mostly IMP at the time) to enterprise-level  
performance.  At the beginning of this work, we looked at the  
bottlenecks of the system.  Two things stood out (there was more than  
two... but these were the first time items on the list and pertinent  
for the present discussion):

1) c-client's performance was atrocious
2) session retrieval/saving took up way too much resources for any  
given request

Admittedly, the former was the much bigger performance issue than the  
latter (2-3 times).  Hence Horde_Imap_Client was born.  But I digress...

As for the latter, we were seeing things like an internal network,  
solely for purposes of interacting with the session storage, being  
completely swamped.  This was because of several factors:

1) We were using session storage as a general cache.  So session sizes  
were way too large.  This was remedied by moving large data items out  
of the session.
2) Along with 1, session data on the wire could be large - 50-100 KB  
may not sound like much, but on every access and with 1,000s of active  
users, it adds up.  An easy way to reduce the load was implementing  
lzf compression of session data.
3) unserializing is not free.  Pretty much dependent on session size (see 1)

...and, important for our current discussion:

4) serializing is not free.  Dependent on 1, but this action is  
completely avoidable if session data does not change in a request.
5) See number 2 above - session data then needs to be sent out on the  
wire... again.
6) There is no guarantee of the performance of the session storage  
backend.  For people who use SQL databases to store session data,  
write times and propagation across a cluster can take forever (one of  
the reasons session data is NOT RECOMMENDED for SQL databases).  Not  
to mention that theses SQL databases may have a caching component in  
front of it - e.g. memcache.  So *2* systems potentially need to be  
updated on every session write

What we learned is that by preventing/limiting session writes,  
performance was vastly improved.

And from a theoretical perspective of how session data is supposed to  
be used, this makes sense.  Session data is there to store things like  
authentication/configuration information.  These are things that  
normally occur once per application upon initial authentication.   
Now... session storage is flexible enough to allow data to be stored  
in it at a later time, but this should be avoided as a  
practice/performance consideration as much as possible.

> I'm with Michael that it's perfectly fine to not being able to set  
> the session timeout on the minute, but rely on PHP's session garbage  
> collection which exact purpose it to kill outdated sessions. If it  
> doesn't do this quick enough for you, and you accept the additional  
> performance penalty (which you do, see above), set a higher  
> probability.

Exactly.  Not only would you lose the performance advantage, but you  
lose the performance advantage WITHOUT ANY ADDITIONAL FUNCTIONALITY  
THAT DOESN'T ALREADY EXIST.

Additionally, I think you are mistaking session expiration as a  
front-line security mechanism.  It isn't.  Obviously, leaving sessions  
active forever is a bad idea.  But the simple fact that a session is  
slightly aged in and of itself is NOT an appreciable security risk.

As I have mentioned before, and Jan repeated, I have yet to hear how  
something like a 30 minute timed session that is not actually removed  
until 45 minutes is in actual security risk.

>> I didn't yet get why it should be a bad idea to write to the session
>> on each request. The only thing I can think of is that the write
>> operation is expensive. But I think horde is probably doing much more
>> expensive operations during a request than updating a session. But
>> I'm not an expert.
>
> I'll leave this to Michael to explain why he has such a strong  
> opinion about this.

See above.

That's why I have to laugh when I see people post on the PHP  
manual/other random internet site and act like session storage is  
"free".  That is so near-sighted, it is comical.  Yes, it works on a  
single-user site.  But expecting that to work on any halfway loaded  
installation with any sort of speed is sort of like expecting an  
sqlite database to be able to scale up to the size of serving all  
Google search requests.