From: Daniel W. <d...@ni...> - 2007-10-29 13:24:30
|
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? -- Squirrelmail Stable 1.4.8 and also offering webmail on Devel 1.5.2 PHP 5.x Hardened with Eaccelerator Apache 2.x Mysql 5.0.x Imapproxy over Dovecot/Maildir all running on Gentoo Linux for ~5,000 users. |
From: Daniel W. <d...@ni...> - 2007-10-30 13:26:07
|
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? > I have a clue about this. I think a plugin or some kind of function tries to access a file or folder incorrectly. This is caught by the index.php which redirects the user to login.php. login.php kills the session! So the next action the user does is greeted with 'you must be logged in'. How big a problem is it if I stop login.php from killing the session? How exactly would that be used to compromise (or otherwise accidentally break) an account? Daniel |
From: Fredrik J. <jer...@sq...> - 2007-10-30 13:51:55
|
Daniel Watts wrote: > 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? > > I have a clue about this. I think a plugin or some kind of function > tries to access a file or folder incorrectly. This is caught by the > index.php which redirects the user to login.php. If this is the case, the web server log should have information on what pages causing the redirection to "index.php" (which will then redirect to "login.php"), making it possible for you to pinpoint the plugin causing the issue. Alternatively the web server configuration causes the redirection, so you might want to check that too. > login.php kills the session! > > So the next action the user does is greeted with 'you must be logged in'. > > How big a problem is it if I stop login.php from killing the session? > > How exactly would that be used to compromise (or otherwise accidentally > break) an account? Sincerely, Fredrik |
From: Paul L. <pa...@sq...> - 2007-10-31 20:17:30
|
On 10/30/07, Daniel Watts <d...@ni...> wrote: > 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. Define "public systems". SM uses cookies just like any other application. > > 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. I think you are barking up the wrong tree. You might start by upgrading - 1.4.8 is full of security issues. > > Not sure what I'm asking specifically here - may be I just want to check > > if we alone are experiencing these issues? > > > > I have a clue about this. I think a plugin or some kind of function > tries to access a file or folder incorrectly. This is caught by the > index.php which redirects the user to login.php. > > login.php kills the session! As it should. > So the next action the user does is greeted with 'you must be logged in'. > > How big a problem is it if I stop login.php from killing the session? Why do you want to fiddle with the core when the problem is broken code elsewhere? You should do the hard work and find the problem itself. > How exactly would that be used to compromise (or otherwise accidentally > break) an account? > > Daniel > |
From: Daniel W. <d...@ni...> - 2007-10-30 17:48:02
|
[sorry if this is a repost - i didn't think the first one sent] > 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? > I have a clue about this. I think a plugin or some kind of function tries to access a file or folder incorrectly. This is caught by the index.php which redirects the user to login.php. login.php kills the session! So the next action the user does is greeted with 'you must be logged in'. How big a problem is it if I stop login.php from killing the session? How exactly would that be used to compromise (or otherwise accidentally break) an account? Daniel |
From: Jon A. <jo...@sq...> - 2007-11-02 03:29:24
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Daniel >> 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? >> > I have a clue about this. I think a plugin or some kind of function > tries to access a file or folder incorrectly. This is caught by the > index.php which redirects the user to login.php. We've actually seen this before. It was triggered by incoming emails, that had bad URLs for images. We'd build a <img src="" /> url, which would trigger index.php to load, and... > login.php kills the session! This was however fixed a few years ago. > So the next action the user does is greeted with 'you must be logged in'. > How big a problem is it if I stop login.php from killing the session? If you don't destroy it, you're likely to get issues with session trampling, and preference corruption. - -- Jon Angliss <jo...@sq... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFHKpmMK4PoFPj9H3MRAuS6AKDk7c/AMTlXn3ijr2TJub4kP4WpUwCgss2C AIat2q83ozPS3b2vxiAoNqg= =QmBE -----END PGP SIGNATURE----- |
From: Daniel W. <d...@ni...> - 2007-11-02 09:41:08
|
>> I have a clue about this. I think a plugin or some kind of function >> tries to access a file or folder incorrectly. This is caught by the >> index.php which redirects the user to login.php. >> > > We've actually seen this before. It was triggered by incoming emails, > that had bad URLs for images. We'd build a <img src="" /> url, which > would trigger index.php to load, and... > > >> login.php kills the session! >> > > This was however fixed a few years ago. > > >> So the next action the user does is greeted with 'you must be logged in'. >> > > Is there any way for login.php to know when this happens? If a full fledged session is underway, perhaps it can intelligently load a 'Are you sure you wish to sign out?' page which, when confirmed, THEN kills the session and loads the standard login form? Then any inadvertent loading of login.php will not trigger session death. |
From: Daniel W. <d...@ni...> - 2007-11-01 12:20:13
|
> >>> 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. > > I think you are barking up the wrong tree. > > You might start by upgrading - 1.4.8 is full of security issues. We're actually working on 1.5.2 - 1.4.8 is only provided as a legecy login incase there were problems on the new system. > >>> Not sure what I'm asking specifically here - may be I just want to check >>> if we alone are experiencing these issues? >>> >> I have a clue about this. I think a plugin or some kind of function >> tries to access a file or folder incorrectly. This is caught by the >> index.php which redirects the user to login.php. >> >> login.php kills the session! > > As it should. > >> So the next action the user does is greeted with 'you must be logged in'. >> >> How big a problem is it if I stop login.php from killing the session? > > Why do you want to fiddle with the core when the problem is broken > code elsewhere? You should do the hard work and find the problem > itself. We were doing hard work - just asking whether we could roll that out as a 'quick fix' in the meantime. As it turns out we finally found the problem yesterday... For your interest: The function general_util.php:get_icon_path() for generating folder list icon images was (correctly) returning null when the Icon Theme was turned off. Our template code was not correctly accounting for null and generating html like <img src="">. In IE it seems that the browser interprets this as a request for the index file of the current page. This was redirected to SMROOT/index.php and subsequently to login.php. Thus every user with themes turned off had their session killed as soon as the folder list loaded. Other browsers usefully ignored the empty src image and did not trigger the problem. ------------------- As an aside - it was really hard to find the problem. We were trying to work out the 'backtrace' for login.php. But since it was being hit via header() redirects, we couldn't find any way of tracking back. $_SERVER didnt' seem to have any useful data (was looking for REFERER info) and the apache access_log didn't seem to offer anything either. How would you have traced the problem back? |
From: Paul L. <pa...@sq...> - 2007-11-02 03:51:52
|
Daniel, please reply on-list. Interestingly, Jon *knew* what your problem was... > >>> 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. > > > > I think you are barking up the wrong tree. > > > > You might start by upgrading - 1.4.8 is full of security issues. > > We're actually working on 1.5.2 - 1.4.8 is only provided as a legecy > login incase there were problems on the new system. Even if 1.4.8 is tertiary, the fact that it is still available for your users means you have a security hole in your systems. The least you can do is make sure you have applied all security patches. > >>> Not sure what I'm asking specifically here - may be I just want to check > >>> if we alone are experiencing these issues? > >>> > >> I have a clue about this. I think a plugin or some kind of function > >> tries to access a file or folder incorrectly. This is caught by the > >> index.php which redirects the user to login.php. > >> > >> login.php kills the session! > > > > As it should. > > > >> So the next action the user does is greeted with 'you must be logged in'. > >> > >> How big a problem is it if I stop login.php from killing the session? > > > > Why do you want to fiddle with the core when the problem is broken > > code elsewhere? You should do the hard work and find the problem > > itself. > > We were doing hard work - just asking whether we could roll that out as > a 'quick fix' in the meantime. > > As it turns out we finally found the problem yesterday... > > For your interest: The function general_util.php:get_icon_path() for > generating folder list icon images was (correctly) returning null when > the Icon Theme was turned off. > > Our template code was not correctly accounting for null and generating > html like <img src="">. > > In IE it seems that the browser interprets this as a request for the > index file of the current page. This was redirected to SMROOT/index.php > and subsequently to login.php. Thus every user with themes turned off > had their session killed as soon as the folder list loaded. > > Other browsers usefully ignored the empty src image and did not trigger > the problem. > > ------------------- > > As an aside - it was really hard to find the problem. We were trying to > work out the 'backtrace' for login.php. But since it was being hit via > header() redirects, we couldn't find any way of tracking back. $_SERVER > didnt' seem to have any useful data (was looking for REFERER info) and > the apache access_log didn't seem to offer anything either. > > How would you have traced the problem back? Maybe with a debugger, maybe the hard way. Nice work, though. If you have suggestions for how to avoid the empty src attribute, we always like good ideas, but I don't know if there is a better way to handle it. |
From: Daniel W. <d...@ni...> - 2007-11-02 13:50:14
|
Paul Lesniewski wrote: > Daniel, please reply on-list. Interestingly, Jon *knew* what your > problem was... Sorry - I'm sure I did press 'reply-all' to make sure a copy went back to the list. May be I messed up. [..snip..] > If you > have suggestions for how to avoid the empty src attribute, we always > like good ideas, but I don't know if there is a better way to handle > it. Thought I'd sent this to the list this morning: >> Is there any way for login.php to know when this happens? If a full fledged session is underway, perhaps it can intelligently load a 'Are you sure you wish to sign out?' page which, when confirmed, THEN kills the session and loads the standard login form? Then any inadvertent loading of login.php will not trigger session death. << |
From: Michael P. <mi...@li...> - 2007-11-02 16:16:09
|
Not sure if my comments made it to the list as it was held by the moderator, (posted with wrong address DOH!) but the issues with sessions dissappearing willy nilly on high volume installations WAS solved by the issues found by our developers related to the garbage collectors on high volume usage sites. <re posted> 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 Thursday 01 November 2007 20:51, Paul Lesniewski wrote: > Daniel, please reply on-list. Interestingly, Jon *knew* what your > problem was... > > > >>> 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. > > > > > > I think you are barking up the wrong tree. > > > > > > You might start by upgrading - 1.4.8 is full of security issues. > > > > We're actually working on 1.5.2 - 1.4.8 is only provided as a legecy > > login incase there were problems on the new system. > > Even if 1.4.8 is tertiary, the fact that it is still available for > your users means you have a security hole in your systems. The least > you can do is make sure you have applied all security patches. > > > >>> Not sure what I'm asking specifically here - may be I just want to > > >>> check if we alone are experiencing these issues? > > >> > > >> I have a clue about this. I think a plugin or some kind of function > > >> tries to access a file or folder incorrectly. This is caught by the > > >> index.php which redirects the user to login.php. > > >> > > >> login.php kills the session! > > > > > > As it should. > > > > > >> So the next action the user does is greeted with 'you must be logged > > >> in'. > > >> > > >> How big a problem is it if I stop login.php from killing the session? > > > > > > Why do you want to fiddle with the core when the problem is broken > > > code elsewhere? You should do the hard work and find the problem > > > itself. > > > > We were doing hard work - just asking whether we could roll that out as > > a 'quick fix' in the meantime. > > > > As it turns out we finally found the problem yesterday... > > > > For your interest: The function general_util.php:get_icon_path() for > > generating folder list icon images was (correctly) returning null when > > the Icon Theme was turned off. > > > > Our template code was not correctly accounting for null and generating > > html like <img src="">. > > > > In IE it seems that the browser interprets this as a request for the > > index file of the current page. This was redirected to SMROOT/index.php > > and subsequently to login.php. Thus every user with themes turned off > > had their session killed as soon as the folder list loaded. > > > > Other browsers usefully ignored the empty src image and did not trigger > > the problem. > > > > ------------------- > > > > As an aside - it was really hard to find the problem. We were trying to > > work out the 'backtrace' for login.php. But since it was being hit via > > header() redirects, we couldn't find any way of tracking back. $_SERVER > > didnt' seem to have any useful data (was looking for REFERER info) and > > the apache access_log didn't seem to offer anything either. > > > > How would you have traced the problem back? > > Maybe with a debugger, maybe the hard way. Nice work, though. If you > have suggestions for how to avoid the empty src attribute, we always > like good ideas, but I don't know if there is a better way to handle > it. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > -- > squirrelmail-devel mailing list > Posting Guidelines: > http://www.squirrelmail.org/wiki/MailingListPostingGuidelines List Address: > squ...@li... > List Archives: > http://news.gmane.org/thread.php?group=gmane.mail.squirrelmail.devel List > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=7139 List > Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered 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. |
From: Jon A. <jo...@sq...> - 2007-11-02 03:32:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Fredrik >>> 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. [..] >>> Not sure what I'm asking specifically here - may be I just want to >>> check if we alone are experiencing these issues? >> I have a clue about this. I think a plugin or some kind of function >> tries to access a file or folder incorrectly. This is caught by the >> index.php which redirects the user to login.php. > If this is the case, the web server log should have information on > what pages causing the redirection to "index.php" (which will then > redirect to "login.php"), making it possible for you to pinpoint the > plugin causing the issue. Alternatively the web server configuration > causes the redirection, so you might want to check that too. Another option would be to edit all the index.php files located below the SquirrelMail directory, with the exception of the single index.php located in the SquirrelMail directory itself, and add an error_log line, with the timestamp, the path, and referrer. - -- Jon Angliss <jo...@sq... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFHKppiK4PoFPj9H3MRAn1oAJ0fB0rWrnrrPp7D5CsZBU11SMKTUwCg+may wKg5YPLnL7DLNN6T6/lMdgQ= =080+ -----END PGP SIGNATURE----- |
From: Daniel W. <d...@ni...> - 2007-11-02 13:44:12
|
[..] > >> If this is the case, the web server log should have information on >> what pages causing the redirection to "index.php" (which will then >> redirect to "login.php"), making it possible for you to pinpoint the >> plugin causing the issue. Alternatively the web server configuration >> causes the redirection, so you might want to check that too. > > Another option would be to edit all the index.php files located below > the SquirrelMail directory, with the exception of the single index.php > located in the SquirrelMail directory itself, and add an error_log > line, with the timestamp, the path, and referrer. > > - -- Exactly what I did do actually but strangely there was no referer information. Even dumping print_r($_SERVER) to the login screen didn't seem to give anything useful in terms of where the redirect had come from. |
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. |
From: Daniel W. <d...@ni...> - 2007-11-05 12:07:23
|
Michael Peddemors wrote: > 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> Michael Thanks for this detailed report. So in summary you were having problems with people being logged out after 'around 30 minutes'? My problem is to do with people being logged out within seconds or minutes of logging in and with plenty of activity that *should* cause the timestamp on the session to update. We actually force-enable the folder refresh as each refresh renews the session timestamp. This way people can leave their session logged in all day without being logged out. Our problem in this instance was solved by working out that one of our image/icon generators was generating an empty img url (src=""). IE interpreted this as a call to index.php which launched the code in login.php, killing the session. Best wishes, Daniel |