From: Michael P. <mi...@wi...> - 2007-10-29 15:58:51
|
Might pass this on that one of our developers stumbled on, where even when cookie timeouts were set for a very long time, customers complained about being logged out, and see if this is an issue that might be affecting others.. The default PHP installation may result in problems around the garbage collection, in systems with a high user count.. <quoted> in php.ini The *session.gc_maxlifetime* is set to 1440 seconds, which is equal to 24 minutes. The *session.gc_probability* is set to 1, which means that the session garbage collector will run 1% of the time* * So in another words, 1% of the requests that initialize a session will trigger the PHP session garbage collector to remove sessions that have a lifetime of older than 24 minutes, which correctly evaluates to the estimate of "approx 30 minutes" reported by <snipped> By observing the session data files in /home/shared/php_sessions/, and setting session.gc_probability to 100, which causes the garbage collector to run on every session initialization, and setting session.gc_maxlifetime to 10 seconds, the garbage collector was indeed killing off all sessions that are older than 10 seconds. To further testing this, I used the steps below, 1. I set session.gc_maxlifetime to 180 (3 minutes) 2. Log in to the admin interface with IE and Firefox on broadside *3. ls *_/home/shared/php_sessions_* show 3 session files with 3 unique session IDs* 3. Wait over 3 minutes 4. Open Firefox on Linux and log in *5. ls *_/home/shared/php_sessions_* shows1 session file, the garage collector killed off the other 2 sessions* 6. Just to make sure, I tabbed back to broadside and click on one of the links on the left menu on the 2 browsers (of the admin interface), and it prompted for authentication. This should explain why we were unable to reproduce this issue on any of our test servers, because there were not enough session initialization requests to trigger the garbage collector in the 24 minute timeframe specified in php.ini. Assuming that this only occurs on customers' servers with a decent amount of users, (over 100 requests in the 24 minute window), this could most definitely be the cause of the issue. <end quote> On Monday 29 October 2007 06:29, Daniel Watts wrote: > Dear Dev team, > > Currently the 'you must be logged in to view this page' message is the > bane of our existence. We receive more issues about this than all other > issues put together. > > Various things conspire to produce this - seemly corrupted cookies (ie > clearing them fixes the problem), antivirus / firewalls that seem to > block cookies etc. > > Sometimes the login will actually get through to webmail.php, load the 3 > frames (with preview pane) and then outrageously show the 'You must be > logged in' error in all 3 frames! > > Is squirrelmail particularly sensitive to cookie issues? I've never > experienced these kinds of problems with the public systems. > > Of course the issue may be our end with our session management but our > other webpages seem to operate fine without sessions / cookies being > lost willy-nilly. > > Particularly the corrupted cookie issue sounds like something > squirrelmail should be able to take care of by completely clearing all > existing cookie records upon login. Having users manually delete old > cookies browser-side is hard work. > > Not sure what I'm asking specifically here - may be I just want to check > if we alone are experiencing these issues? -- "Products, Services and Support..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - Wizard IT Services "Servicing the ISP, Telco and Enterprise Markets since 1997" ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "Wizard IT" is a company TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. |