On Wed, 06 Sep 2006 08:17:56 +0200, Thomas Bruederli roundcube@gmail.com wrote:
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...
I get this often - but I don't know how to trace it out. I've turned up logging to '4', but it didn't list anything around the time I got kicked out to the login screen. Luckily it had already saved a draft, so I only lost a little bit, but still, something is fishy. If anyone has an idea of how I can better trace things out (set it to '8'?) I'll do it to try to find the issue.
Thanks
P
Mr. B. Vrieling wrote:
Specifically, my suspicion is that the sess_gc() function is deleting
sessions incorrectly (ie. prematurely).
QUESTIONS:
- 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.
- 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.
- 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
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
-- http://fak3r.com - you don't have to kick it