Ticket #1483986 (Bugs) Session expires

Thomas Bruederli roundcube at gmail.com
Wed Sep 6 08:17:56 CEST 2006


I hope I can give you some answers to your questions about session
handling in RoundCube. Unfortunately, I cannot reproduce any session
timeouts and because of that I'm unable to fix the bug...


Mr. B. Vrieling wrote:
> Specifically, my suspicion is that the sess_gc() function is deleting sessions incorrectly (ie. prematurely).
> 
> QUESTIONS:
> 
> 1. Why the custom session handling code? Was it for scaling with multiple servers? If I has only one server (a simple environment), what does storing the sessions in a database accomplish?

I wanted to have all date stored in one place initially. Also there are
(or have been) cache records that are related to a session and that
should be deleted when the session ends or within the garbage collection
routine. Having the sessions table replicated on several servers is just
something theoretical that hasn't been used so far.
> 
> 2. If I disabled the garbage collection code (sess_gc) and allowed the stale sessions to collect rather than have them deleted, what would the impact of that be other than disk space in the database? I might manually hoof them all once a week.

Should work. You can watch the table grow and remove old sessions
manually or with a cron job.
> 
> 3. If the answer to the final part of #1 is "not a lot", what would happen if I did not install the custom session handlers and just let PHP's own code do it?

Of course you can try that. Just remove the lines 85/86 in main.inc
where the custom session handler is included.
> 
> I might be all wet and not understanding at all what the code is supposed to do. If so, please forgive me. However, I have users who really want to use RoundCube but the session expiry bug is killing them. I need a tactical solution until the real issue is addressed.
> 
Another place to debug this problem is in function
rcmail_authenticate_session() which can be found in main.inc. If you set
$CONFIG['session_lifetime'] to FALSE, the time check will be avoided but
the validity of the session still will be checked in
rcmail_authenticate_session()

Some time ago, I removed the _auth hash in all URLs and added a second
cookie that changes every 5 minutes. When the client sends it's
keep-alive signal, a new cookie will be sent. To disable this security
check, you simple let rcmail_authenticate_session() always return true.

I hope these explanations will help you debug this. I'm really keen on
what's the problem here...

Regards,
Thomas




More information about the Dev mailing list