From: tinynumbers a. <ad...@ti...> - 2002-07-24 13:24:58
|
On my first attempt to login to squirrelmail, every time, I get an error = message like this: ERROR=20 You must be logged in to access this page. =20 ... with a link back to the login page. When I click that link back to = the login page, the second attempt is always successful. My guess is that the second attempt works because this link back to the = login page includes a PHPSESSID in a GET parameter; probably the first = post from the login page (to ..../src/redirect.php) is not = getting/maintaining the session ID? Any suggestions on how to avoid this (minor) hassle? I'm currently running squirrelmail 1.2.7 on php 4.2.1 with apache 2.0.39 = on Linux. Also possibly worth mentioning is that I'm accessing my webmail server = via ProxyPass/ProxyPassReverse on a different apache server in the same = net (I only have open port-80 access to one of my web servers, and it's = not the one that's running squirrelmail, so I pass through to the = internal server). This doesn't seem to have any problems with other = apps, though; it appears to be quite transparent. Thanks, - David |
From: Jon T. <jo...@tg...> - 2002-07-25 01:59:15
|
On Wed, 2002-07-24 at 06:24, tinynumbers admin wrote: > On my first attempt to login to squirrelmail, every time, I get an error message like this: > > ERROR > You must be logged in to access this page. > > ... with a link back to the login page. When I click that link back to the login page, the second attempt is always successful. > > My guess is that the second attempt works because this link back to the login page includes a PHPSESSID in a GET parameter; probably the first post from the login page (to ..../src/redirect.php) is not getting/maintaining the session ID? > Good observation. > I'm currently running squirrelmail 1.2.7 on php 4.2.1 with apache 2.0.39 on Linux. > IIRC, this issue came up on the list with other people running apache 2.0.x, but I don't remember seeing a solution. Check the list archives to be sure though. - Jon |
From: Andrew <an...@ar...> - 2002-07-26 01:29:08
|
Hold on to your hats, I may have found a solution to this login problem. I got frustrated enough with the first time login error that I wiped out my php and SM installations and reinstalled them both. I was using php 4.2.1 and SM 2.1.6 and now I'm using php 4.2.2 and SM 2.1.7. I also added another configure option when compiling php: --enable-trans-sid This enables transparent session ids, whatever those are. From other posts, it looked like SM might be having trouble establishing a session id during the first login attempt so I thought I'd try the above option just to see what would happen. Well, now I can log in to SM the first time with no error! I've tried this with both Netscape 4.79 and IE 5. Whether this is because of the configure option I added to php or because I am using different versions, I don't know. I am understandably reluctant to reinstall either SM or php now that I have it all working. To all out there that are experiencing the first login problem, I hope this finally solves it for you. Andrew |
From: tinynumbers a. <ad...@ti...> - 2002-07-26 04:10:39
|
> Hold on to your hats, I may have found a solution to this login problem. > > I got frustrated enough with the first time login error that I wiped out > my php and SM installations and reinstalled them both. I was using php > 4.2.1 and SM 2.1.6 and now I'm using php 4.2.2 and SM 2.1.7. I also > added another configure option when compiling php: > > --enable-trans-sid > <etc> so that didn't do it for me, but in the process of trying it, i came across this option in php.ini: ; Initialize session on request startup. session.auto_start = 0 ... and realized that looked definitely related to my issue. and changing that value to 1 (and restarting httpd) FIXED IT! the enable-trans-sid compile option didn't seem to solve the problem, but turning on session.auto_start did. thanks for the brainstorming help. - david |
From: tinynumbers a. <ad...@ti...> - 2002-07-25 02:04:26
|
FWIW, i actually noticed that you don't have to use that link back to the login page in order for login to succeed; just hitting the "back" button and then re-trying will work. i'll consult the archives and see what i can find; i did find a post about this in the wiki (http://www.squirrelmail.org/wiki/LoginError) but none of the suggestions there solved my problem... - david ----- Original Message ----- From: "Jon Tai" <jo...@tg...> To: "tinynumbers admin" <ad...@ti...> Cc: <squ...@li...> Sent: Wednesday, July 24, 2002 10:01 PM Subject: Re: [SM-USERS] error on first login attempt, success on second > On Wed, 2002-07-24 at 06:24, tinynumbers admin wrote: > > On my first attempt to login to squirrelmail, every time, I get an error message like this: > > > > ERROR > > You must be logged in to access this page. > > > > ... with a link back to the login page. When I click that link back to the login page, the second attempt is always successful. > > > > My guess is that the second attempt works because this link back to the login page includes a PHPSESSID in a GET parameter; probably the first post from the login page (to ..../src/redirect.php) is not getting/maintaining the session ID? > > > > Good observation. > > > I'm currently running squirrelmail 1.2.7 on php 4.2.1 with apache 2.0.39 on Linux. > > > > IIRC, this issue came up on the list with other people running apache > 2.0.x, but I don't remember seeing a solution. Check the list archives > to be sure though. > > - Jon > > > |
From: Jason M. <ja...@st...> - 2002-07-25 14:39:15
|
tinynumbers admin said: > FWIW, i actually noticed that you don't have to use that link back to > the login page in order for login to succeed; just hitting the "back" > button and then re-trying will work. > > i'll consult the archives and see what i can find; i did find a post > about this in the wiki (http://www.squirrelmail.org/wiki/LoginError) but > none of the suggestions there solved my problem... > > - david > > > ----- Original Message ----- > From: "Jon Tai" <jo...@tg...> > To: "tinynumbers admin" <ad...@ti...> > Cc: <squ...@li...> > Sent: Wednesday, July 24, 2002 10:01 PM > Subject: Re: [SM-USERS] error on first login attempt, success on second > > >> On Wed, 2002-07-24 at 06:24, tinynumbers admin wrote: >> > On my first attempt to login to squirrelmail, every time, I get an >> error > message like this: >> > >> > ERROR >> > You must be logged in to access this page. >> > >> > ... with a link back to the login page. When I click that link back >> to > the login page, the second attempt is always successful. >> > >> > My guess is that the second attempt works because this link back to >> the > login page includes a PHPSESSID in a GET parameter; probably the first > post from the login page (to ..../src/redirect.php) is not > getting/maintaining the session ID? >> > >> >> Good observation. >> >> > I'm currently running squirrelmail 1.2.7 on php 4.2.1 with apache >> 2.0.39 > on Linux. >> > >> >> IIRC, this issue came up on the list with other people running apache >> 2.0.x, but I don't remember seeing a solution. Check the list >> archives to be sure though. >> >> - Jon >> >> >> I have been keeping an eye on this issue and there is a bug report currently in proccess. It seems that this is limited to Apache 2 setups and I do not think a fix has been found yet. Any suggestions are welcome :) \___ Jason Munro \___ AIM:jmunr0 \__ ja...@st... \__ http://www.sunflower.com/~jmunro/ |
From: Jonathan A. <jon...@ar...> - 2002-07-26 23:09:01
|
On Fri, Jul 26, 2002 at 12:11:59AM -0400, tinynumbers admin wrote: | so that didn't do it for me, but in the process of trying it, i came | across this option in php.ini: | | ; Initialize session on request startup. | session.auto_start = 0 Aha, I had just come to the conclusion that attacking the session.auto_start variable was likely to be related to this bug as well. Trying to set it in the httpd.conf file didn't seem to work right, though.. <IfModule mod_php4.c> php_admin_value register_globals 1 php_admin_value session.autostart 1 </IfModule> Creating an 'info.php' file containing <? phpinfo(); ?> helped me to find the appropriate location for the php.ini file for my install, though, and.. it worked! This has been not been working properly for us for months. The session.auto_start issue should most definitely be in a FAQ someplace. | ... and realized that looked definitely related to my issue. and changing | that value to 1 (and restarting httpd) FIXED IT! the enable-trans-sid | compile option didn't seem to solve the problem, but turning on | session.auto_start did. | | thanks for the brainstorming help. | | - david -- ------------------------------------------------------------------------------- Jonathan Abbey jon...@ar... Applied Research Laboratories The University of Texas at Austin Ganymede, a GPL'ed metadirectory for UNIX http://www.arlut.utexas.edu/gash2 |
From: Alberto <al...@ma...> - 2002-07-27 07:20:40
|
I found some little problems in Brazilian Portuguese translation and solved them to my server. So... I would like to post them to SquirrelMail people developers.. how could I do this quickly without need to register in developers mail-list?? Thanx, Alberto V. M. Apple Developer Connection member since 1999 --- Marlin Project http://macosx.homeunix.org |
From: Jason M. <ja...@st...> - 2002-07-27 17:24:37
|
Jonathan Abbey said: > On Fri, Jul 26, 2002 at 12:11:59AM -0400, tinynumbers admin wrote: | so > that didn't do it for me, but in the process of trying it, i came | > across this option in php.ini: > | > | ; Initialize session on request startup. > | session.auto_start = 0 > > Aha, I had just come to the conclusion that attacking the > session.auto_start variable was likely to be related to this bug as > well. Trying to set it in the httpd.conf file didn't seem to work > right, though.. > > <IfModule mod_php4.c> > php_admin_value register_globals 1 > php_admin_value session.autostart 1 > </IfModule> > > Creating an 'info.php' file containing <? phpinfo(); ?> helped me to > find the appropriate location for the php.ini file for my install, > though, and.. > > it worked! > > This has been not been working properly for us for months. The > session.auto_start issue should most definitely be in a FAQ someplace. > > | ... and realized that looked definitely related to my issue. and > changing | that value to 1 (and restarting httpd) FIXED IT! the > enable-trans-sid | compile option didn't seem to solve the problem, but > turning on > | session.auto_start did. I almost hate to add to the confusion regarding this double login situation, but what the heck :) First off I have a production server that I just upgraded to 4.2.2 Monday and session.auto_start is NOT enabled. Its an Apache 1.3.26/Courier/Qmail setup on Redhat. No login problems at all. OK, I also have an Apache 2.0.39/PHP 4.2.2 test system running Courier/Postfix. Well session.auto_start did not have any effect on the double login issue on Apache 2. Its still not working properly. I found a little bug report regarding some similar symptoms at the php site. It had to do with session cookies not being available until a page was refreshed with Apache 2. Sound familiar ? Regardless of exactly what settings 'fix' things for different sites, how about a "recommended php.ini settings" file in the next Squirrelmail release, where we can put all the various settings for your php.ini that seem to be the most Squirrelmail friendly :) \___ Jason Munro \___ AIM:jmunr0 \__ ja...@st... \__ http://www.sunflower.com/~jmunro/ |
From: Andrew <an...@ar...> - 2002-07-28 00:00:22
|
Jason Munro wrote: > > I almost hate to add to the confusion regarding this double login > situation, but what the heck :) > First off I have a production server that I just upgraded to 4.2.2 > Monday and session.auto_start is NOT enabled. Its an Apache > 1.3.26/Courier/Qmail setup on Redhat. No login problems at all. > OK, I also have an Apache 2.0.39/PHP 4.2.2 test system running > Courier/Postfix. Well session.auto_start did not have any effect on the > double login issue on Apache 2. Its still not working properly. > I found a little bug report regarding some similar symptoms at the php > site. It had to do with session cookies not being available until a page > was refreshed with Apache 2. Sound familiar ? > I've been doing some more investigating of this problem myself and the evidence is definitely pointing to a session cookie problem. Here is all the relevant software I'm using: Apache 2.0.39 PHP 4.2.2 SM 1.2.7 Netscape Navigator 4.79 Internet Explorer 5.0 I also have session.auto_start set to 1. I used ethereal to watch the packets flying around when connecting to SM with either Netscape or IE. Here's what I found. IE talks to SM using HTTP 1.1 and receives a PHPSESSID cookie when it receives the SM login page. First time logins work with IE. Netscape talks to SM using HTTP 1.0 and does not receive a PHPSESSID cookie when it receives the SM login page. First time logins do not work with Netscape. Ironically enough, the PHPSESSID cookie is received with the login failure page which, I'm guessing, is why all subsequent login attempts succeed. Could this problem revolve around which version of HTTP your browser uses? Does anyone else have a packet sniffer handy who could confirm my results? In any case, perhaps searching the PHP and Apache mailing list archives for problems specific to certain versions of HTTP would shed some light on this ongoing problem. Andrew |