Still problems with 1.4.19 and "you must be logged in" error
|
View:
New views
18 Messages
—
Rating Filter:
Alert me
|
 |
Still problems with 1.4.19 and "you must be logged in" error
by Rafael Martinez, Guerrero
::
Rate this Message:
Hello
We are still having big problems with cookies under testing, before we upgrade to 1.4.19. These problems are stopping us from upgrading from 1.4.17 to 1.4.19 because with 20.000+ user of squirrelmail in our system, having to delete all squirrelmail cookie information from their browser will not be a practical solution (not to mention the telefon queue we would get in the support senter when squirrelmail stops working for all of them at the same time) The problem is the one explained in: [SM-USERS] upgrade to 1.4.18 gives "you must be logged in" error [SM-USERS] 1.4.18 bug with src/redirect.php on php4.3.3 Description of the problem: After upgrading to 1.4.19, the only page an user will see after logging in will be the default page with the left/right frame and folders/INBOX information. Any click after this point will show a "you must be logged in" error. The only way of getting rid of this problem is deleting all cookie information from squirrelmail in your browser or reverting to 1.4.17. Deleting this code in src/redirect.php: -------------------------------------------------------------------- if (function_exists('session_regenerate_id')) { session_regenerate_id(); // re-send session cookie so we get the right parameters on it // (such as HTTPOnly, if necessary - PHP doesn't do this itself sqsetcookie(session_name(),session_id(),false,$base_uri); } -------------------------------------------------------------------- Or applying this patch to src/redirect.php: -------------------------------------------------------------------- -- src/redirect.php (revision 13680) +++ src/redirect.php (working copy) @@ -80,6 +80,8 @@ */ if (function_exists('session_regenerate_id')) { session_regenerate_id(); + if (!headers_sent()) + sqsetcookie(session_name(),session_id(),false,$base_uri); } $onetimepad = OneTimePadCreate(strlen($secretkey)); -------------------------------------------------------------------- Do not help and the problem is still there after these changes. I think that the problem is not in src/redirect.php but in function/global.php. This new code in 1.4.19 looks like a candidate for being the origin of this problem, don't you think?: -------------------------------------------------------------------- if (isset($_COOKIE[session_name()])) { sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri); /* * Make sure to kill /src and /src/ cookies, just in case there are * some left-over or malicious ones set in user's browser. * NB: Note that an attacker could try to plant a cookie for one * of the /plugins/* directories. Such cookies can block * access to certain plugin pages, but they do not influence * or fixate the $base_uri cookie, so we don't worry about * trying to delete all of them here. */ sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'src'); sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'src/'); } if (isset($_COOKIE['key'])) sqsetcookie('key', 'SQMTRASH', 1, $base_uri); /* Make sure new session id is generated on subsequent session_start() */ unset($_COOKIE[session_name()]); unset($_GET[session_name()]); unset($_POST[session_name()]); -------------------------------------------------------------------- Some tecnical information about our system: - RHELS 5.3, Apache/2.2.11, PHP.5.2.8 - All traffic between the browser and apache uses SSL (port 443). - Session data and userpref/addressbook are saved in a PostgreSQL database. Do you need any more information? How can we help to fix this problem? regards -- Rafael Martinez, <r.m.guerrero@...> Center for Information Technology Services University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/ ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: [SM-USERS] Still problems with 1.4.19 and "you must be logged in" error
by derekwnek
::
Rate this Message:
Hello
We are still having big problems with cookies under testing, before we upgrade to 1.4.19. These problems are stopping us from upgrading from 1.4.17 to 1.4.19 because with 20.000+ user of squirrelmail in our system, having to delete all squirrelmail cookie information from their browser will not be a practical solution (not to mention the telefon queue we would get in the support senter when squirrelmail stops working for all of them at the same time) The problem is the one explained in: [SM-USERS] upgrade to 1.4.18 gives "you must be logged in" error [SM-USERS] 1.4.18 bug with src/redirect.php on php4.3.3 Description of the problem: After upgrading to 1.4.19, the only page an user will see after logging in will be the default page with the left/right frame and folders/INBOX information. Any click after this point will show a "you must be logged in" error. The only way of getting rid of this problem is deleting all cookie information from squirrelmail in your browser or reverting to 1.4.17. Deleting this code in src/redirect.php: -------------------------------------------------------------------- if (function_exists('session_regenerate_id')) { session_regenerate_id(); // re-send session cookie so we get the right parameters on it // (such as HTTPOnly, if necessary - PHP doesn't do this itself sqsetcookie(session_name(),session_id(),false,$base_uri); } -------------------------------------------------------------------- Or applying this patch to src/redirect.php: -------------------------------------------------------------------- -- src/redirect.php (revision 13680) +++ src/redirect.php (working copy) @@ -80,6 +80,8 @@ */ if (function_exists('session_regenerate_id')) { session_regenerate_id(); + if (!headers_sent()) + sqsetcookie(session_name(),session_id(),false,$base_uri); } $onetimepad = OneTimePadCreate(strlen($secretkey)); -------------------------------------------------------------------- Do not help and the problem is still there after these changes. I think that the problem is not in src/redirect.php but in function/global.php. This new code in 1.4.19 looks like a candidate for being the origin of this problem, don't you think?: -------------------------------------------------------------------- if (isset($_COOKIE[session_name()])) { sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri); /* * Make sure to kill /src and /src/ cookies, just in case there are * some left-over or malicious ones set in user's browser. * NB: Note that an attacker could try to plant a cookie for one * of the /plugins/* directories. Such cookies can block * access to certain plugin pages, but they do not influence * or fixate the $base_uri cookie, so we don't worry about * trying to delete all of them here. */ sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'src'); sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'src/'); } if (isset($_COOKIE['key'])) sqsetcookie('key', 'SQMTRASH', 1, $base_uri); /* Make sure new session id is generated on subsequent session_start() */ unset($_COOKIE[session_name()]); unset($_GET[session_name()]); unset($_POST[session_name()]); -------------------------------------------------------------------- Some tecnical information about our system: - RHELS 5.3, Apache/2.2.11, PHP.5.2.8 - All traffic between the browser and apache uses SSL (port 443). - Session data and userpref/addressbook are saved in a PostgreSQL database. Do you need any more information? How can we help to fix this problem? regards -- Rafael Martinez, <r.m.guerrero@...> Center for Information Technology Services University of Oslo, Norway We are experiencing the same exact type problems as mentioned above by Rafael and are also running squirrelmail 1.4.19 on RHEL 5.3 with Apache 2.2.11 and PHP 5.2.5. I have tried commenting the whole IF statement around line 82 in src/redirect.php and that did not work for us. I am using IE 7 to test. What I am seeing is intermittent and varies as such: 1. Sometimes when browsing to src/login.php I am redirected to the login error page instead. 2. When browsing to src/login.php and not redirected to the login page and successfully log in, either both frames or one of the frames will be blank while the other correctly displays the web content. 3. When browsing to src/login.php and not redirected to the login page and successfully login, either both frames or one of the frames will display webpage cannot be displayed while the other correctly displays the web content. 4. Clicking on IE's refresh sometimes successfully refreshes the faulted frame and other times takes you to the login error page. 5. After logging in with both frames working and just leaving the browser sitting there with Inbox messages displayed, the left pane either goes blank or displays webpage cannot be displayed. I think it must be occurring during an auto refresh of the folders pane (as set in the folder options) . When I simply reconfigure httpd.conf to point to webmail-1.4.17 vice webmail-1.4.19 and restart the httpd service all of the above problems go away. I have not seen a response back to Rafael's email above yet and was wondering what the status of this is and if there is something that can be done to correct this. I am anxious to go back to 1.4.19 because of all of the security fixes contained in 1.4.18 including the very important fix regarding remote execution of server side code. r/Derek Wnek ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: [SM-USERS] Still problems with 1.4.19 and "you must be logged in" error
by Rafael Martinez, Guerrero
::
Rate this Message:
dwnek@... wrote:
[....] > > When I simply reconfigure httpd.conf to point to webmail-1.4.17 vice > webmail-1.4.19 and restart the httpd service all of the above problems go > away. > > I have not seen a response back to Rafael's email above yet and was > wondering what the status of this is and if there is something that can be > done to correct this. I am anxious to go back to 1.4.19 because of all of > the security fixes contained in 1.4.18 including the very important fix > regarding remote execution of server side code. > Hello We have found a way to avoid these problems. We have deleted this code in src/redirect.php: -------------------------------------------------------------------- if (function_exists('session_regenerate_id')) { session_regenerate_id(); // re-send session cookie so we get the right parameters on it // (such as HTTPOnly, if necessary - PHP doesn't do this itself sqsetcookie(session_name(),session_id(),false,$base_uri); } ------------------------------------------------------------------- and this code in function/global.php: -------------------------------------------------------------------- sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'src'); sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'src/'); -------------------------------------------------------------------- Maybe some of the developers can explain the implications of these changes. With these changes, users logged in squirrelmail under the upgrade will get the "you must be logged in" error, but everything will work without problems when they logg in again after this. It have been a nightmare since 1.4.19 was released knowing the version we had in production had serious security problems and not been able to upgrade. We are very disappointed with the null respond from developers we have had on this issue. regards -- Rafael Martinez, <r.m.guerrero@...> Center for Information Technology Services University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/ ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: [SM-USERS] Still problems with 1.4.19 and "you must be logged in" error
by Rafael Martinez, Guerrero
::
Rate this Message:
Rafael Martinez wrote:
> > With these changes, users logged in squirrelmail under the upgrade will > get the "you must be logged in" error, but everything will work without > problems when they logg in again after this. > Correction, users will not have to login again after the upgrade is finish. regards -- Rafael Martinez, <r.m.guerrero@...> Center for Information Technology Services University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/ ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: [SM-USERS] Still problems with 1.4.19 and "you must be logged in" error
by Jon Angliss
::
Rate this Message:
On Mon, 08 Jun 2009 11:30:12 +0200, Rafael Martinez
<r.m.guerrero@...> wrote: >dwnek@... wrote: >[....] >> >> When I simply reconfigure httpd.conf to point to webmail-1.4.17 vice >> webmail-1.4.19 and restart the httpd service all of the above problems go >> away. >> >> I have not seen a response back to Rafael's email above yet and was >> wondering what the status of this is and if there is something that can be >> done to correct this. I am anxious to go back to 1.4.19 because of all of >> the security fixes contained in 1.4.18 including the very important fix >> regarding remote execution of server side code. >> > >Hello > >We have found a way to avoid these problems. > >We have deleted this code in src/redirect.php: > >-------------------------------------------------------------------- >if (function_exists('session_regenerate_id')) { > > session_regenerate_id(); > > // re-send session cookie so we get the right parameters on it > // (such as HTTPOnly, if necessary - PHP doesn't do this itself > > sqsetcookie(session_name(),session_id(),false,$base_uri); >} >------------------------------------------------------------------- > >and this code in function/global.php: > >-------------------------------------------------------------------- > >sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'src'); >sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . >'src/'); > >-------------------------------------------------------------------- > >Maybe some of the developers can explain the implications of these changes. It was in response to a security report. We try to overwrite the cookies that may already be set in the src/ directory to stop a hacker from attempting to steal information. >With these changes, users logged in squirrelmail under the upgrade will >get the "you must be logged in" error, but everything will work without >problems when they logg in again after this. I've not seen the issue myself, but then cannot say I run on a large variety of systems, so you may be coming across a combination we don't know about. What are you settings for session.auto_start in your php.ini? It's probably possibly that we should be pushing the call to the regenerate_id into src/login.php instead of src/redirect.php. >It have been a nightmare since 1.4.19 was released knowing the version >we had in production had serious security problems and not been able to >upgrade. >We are very disappointed with the null respond from developers we have >had on this issue. I did notice that your report says you're using PHP 5.2.8, Chris Hoogendyk reported a similar issue with 1.4.18, and had several platforms upgraded. Those running PHP 4.x worked, whilst the one running 5.2 failed. I'm running 5.2.0 without issues, so I'm wondering if there might be additional changes that might cause some problems, or a link between browsers too. -- Jonathan Angliss <jon@...> ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: [SM-USERS] Still problems with 1.4.19 and "you must be logged in" error
by SquirrelMail Email List
::
Rate this Message:
On Thu, 11 Jun 2009, Jonathan Angliss wrote: > On Mon, 08 Jun 2009 11:30:12 +0200, Rafael Martinez > <r.m.guerrero@...> wrote: > >> dwnek@... wrote: >> [....] >>> >>> When I simply reconfigure httpd.conf to point to webmail-1.4.17 vice >>> webmail-1.4.19 and restart the httpd service all of the above problems go >>> away. >>> >>> I have not seen a response back to Rafael's email above yet and was >>> wondering what the status of this is and if there is something that can be >>> done to correct this. I am anxious to go back to 1.4.19 because of all of >>> the security fixes contained in 1.4.18 including the very important fix >>> regarding remote execution of server side code. >>> >> >> Hello >> >> We have found a way to avoid these problems. >> >> We have deleted this code in src/redirect.php: >> >> -------------------------------------------------------------------- >> if (function_exists('session_regenerate_id')) { >> >> session_regenerate_id(); >> >> // re-send session cookie so we get the right parameters on it >> // (such as HTTPOnly, if necessary - PHP doesn't do this itself >> >> sqsetcookie(session_name(),session_id(),false,$base_uri); >> } >> ------------------------------------------------------------------- >> >> and this code in function/global.php: >> >> -------------------------------------------------------------------- >> >> sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'src'); >> sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . >> 'src/'); >> >> -------------------------------------------------------------------- > >> >> Maybe some of the developers can explain the implications of these changes. > > It was in response to a security report. We try to overwrite the > cookies that may already be set in the src/ directory to stop a hacker > from attempting to steal information. > >> With these changes, users logged in squirrelmail under the upgrade will >> get the "you must be logged in" error, but everything will work without >> problems when they logg in again after this. > > I've not seen the issue myself, but then cannot say I run on a large > variety of systems, so you may be coming across a combination we don't > know about. > > What are you settings for session.auto_start in your php.ini? > > It's probably possibly that we should be pushing the call to the > regenerate_id into src/login.php instead of src/redirect.php. > >> It have been a nightmare since 1.4.19 was released knowing the version >> we had in production had serious security problems and not been able to >> upgrade. > >> We are very disappointed with the null respond from developers we have >> had on this issue. > > I did notice that your report says you're using PHP 5.2.8, Chris > Hoogendyk reported a similar issue with 1.4.18, and had several > platforms upgraded. Those running PHP 4.x worked, whilst the one > running 5.2 failed. I'm running 5.2.0 without issues, so I'm > wondering if there might be additional changes that might cause some > problems, or a link between browsers too. > > -- > Jonathan Angliss > <jon@...> > So is this the final word on this problem? We are having the same problem with our setup. Thanks, Ken ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: Still problems with 1.4.19 and "you must be logged in" error
by Jon Angliss
::
Rate this Message:
On Wed, 17 Jun 2009 15:16:37 -0700 (PDT), SquirrelMail Email List
<sm@...> wrote: > > >On Thu, 11 Jun 2009, Jonathan Angliss wrote: > >> On Mon, 08 Jun 2009 11:30:12 +0200, Rafael Martinez >> <r.m.guerrero@...> wrote: >> >>> dwnek@... wrote: >>> [....] >>>> >>>> When I simply reconfigure httpd.conf to point to webmail-1.4.17 vice >>>> webmail-1.4.19 and restart the httpd service all of the above problems go >>>> away. >>>> >>>> I have not seen a response back to Rafael's email above yet and was >>>> wondering what the status of this is and if there is something that can be >>>> done to correct this. I am anxious to go back to 1.4.19 because of all of >>>> the security fixes contained in 1.4.18 including the very important fix >>>> regarding remote execution of server side code. >>>> >>> >>> Hello >>> >>> We have found a way to avoid these problems. >>> >>> We have deleted this code in src/redirect.php: >>> >>> -------------------------------------------------------------------- >>> if (function_exists('session_regenerate_id')) { >>> >>> session_regenerate_id(); >>> >>> // re-send session cookie so we get the right parameters on it >>> // (such as HTTPOnly, if necessary - PHP doesn't do this itself >>> >>> sqsetcookie(session_name(),session_id(),false,$base_uri); >>> } >>> ------------------------------------------------------------------- >>> >>> and this code in function/global.php: >>> >>> -------------------------------------------------------------------- >>> >>> sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'src'); >>> sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . >>> 'src/'); >>> >>> -------------------------------------------------------------------- >> >>> >>> Maybe some of the developers can explain the implications of these changes. >> >> It was in response to a security report. We try to overwrite the >> cookies that may already be set in the src/ directory to stop a hacker >> from attempting to steal information. >> >>> With these changes, users logged in squirrelmail under the upgrade will >>> get the "you must be logged in" error, but everything will work without >>> problems when they logg in again after this. >> >> I've not seen the issue myself, but then cannot say I run on a large >> variety of systems, so you may be coming across a combination we don't >> know about. >> >> What are you settings for session.auto_start in your php.ini? >> >> It's probably possibly that we should be pushing the call to the >> regenerate_id into src/login.php instead of src/redirect.php. >> >>> It have been a nightmare since 1.4.19 was released knowing the version >>> we had in production had serious security problems and not been able to >>> upgrade. >> >>> We are very disappointed with the null respond from developers we have >>> had on this issue. >> >> I did notice that your report says you're using PHP 5.2.8, Chris >> Hoogendyk reported a similar issue with 1.4.18, and had several >> platforms upgraded. Those running PHP 4.x worked, whilst the one >> running 5.2 failed. I'm running 5.2.0 without issues, so I'm >> wondering if there might be additional changes that might cause some >> problems, or a link between browsers too. >> >> -- >> Jonathan Angliss >> <jon@...> >> > >So is this the final word on this problem? We are having the same problem >with our setup. I had not heard anything back from the original poster of the issue, so I'm not sure what I can say. As you're able to reproduce the same issue, can you provide us with some more details? Platform? Web server? PHP version? Plugin details? -- Jonathan Angliss <jon@...> ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: [SM-USERS] Still problems with 1.4.19 and "you must be logged in" error
by SquirrelMail Email List
::
Rate this Message:
On Thu, 18 Jun 2009, Jonathan Angliss wrote: > On Wed, 17 Jun 2009 15:16:37 -0700 (PDT), SquirrelMail Email List > <sm@...> wrote: > >> >> >> On Thu, 11 Jun 2009, Jonathan Angliss wrote: >> >>> On Mon, 08 Jun 2009 11:30:12 +0200, Rafael Martinez >>> <r.m.guerrero@...> wrote: >>> >>>> dwnek@... wrote: >>>> [....] >>>>> >>>>> When I simply reconfigure httpd.conf to point to webmail-1.4.17 vice >>>>> webmail-1.4.19 and restart the httpd service all of the above problems go >>>>> away. >>>>> >>>>> I have not seen a response back to Rafael's email above yet and was >>>>> wondering what the status of this is and if there is something that can be >>>>> done to correct this. I am anxious to go back to 1.4.19 because of all of >>>>> the security fixes contained in 1.4.18 including the very important fix >>>>> regarding remote execution of server side code. >>>>> >>>> >>>> Hello >>>> >>>> We have found a way to avoid these problems. >>>> >>>> We have deleted this code in src/redirect.php: >>>> >>>> -------------------------------------------------------------------- >>>> if (function_exists('session_regenerate_id')) { >>>> >>>> session_regenerate_id(); >>>> >>>> // re-send session cookie so we get the right parameters on it >>>> // (such as HTTPOnly, if necessary - PHP doesn't do this itself >>>> >>>> sqsetcookie(session_name(),session_id(),false,$base_uri); >>>> } >>>> ------------------------------------------------------------------- >>>> >>>> and this code in function/global.php: >>>> >>>> -------------------------------------------------------------------- >>>> >>>> sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'src'); >>>> sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . >>>> 'src/'); >>>> >>>> -------------------------------------------------------------------- >>> >>>> >>>> Maybe some of the developers can explain the implications of these changes. >>> >>> It was in response to a security report. We try to overwrite the >>> cookies that may already be set in the src/ directory to stop a hacker >>> from attempting to steal information. >>> >>>> With these changes, users logged in squirrelmail under the upgrade will >>>> get the "you must be logged in" error, but everything will work without >>>> problems when they logg in again after this. >>> >>> I've not seen the issue myself, but then cannot say I run on a large >>> variety of systems, so you may be coming across a combination we don't >>> know about. >>> >>> What are you settings for session.auto_start in your php.ini? >>> >>> It's probably possibly that we should be pushing the call to the >>> regenerate_id into src/login.php instead of src/redirect.php. >>> >>>> It have been a nightmare since 1.4.19 was released knowing the version >>>> we had in production had serious security problems and not been able to >>>> upgrade. >>> >>>> We are very disappointed with the null respond from developers we have >>>> had on this issue. >>> >>> I did notice that your report says you're using PHP 5.2.8, Chris >>> Hoogendyk reported a similar issue with 1.4.18, and had several >>> platforms upgraded. Those running PHP 4.x worked, whilst the one >>> running 5.2 failed. I'm running 5.2.0 without issues, so I'm >>> wondering if there might be additional changes that might cause some >>> problems, or a link between browsers too. >>> >>> -- >>> Jonathan Angliss >>> <jon@...> >>> >> >> So is this the final word on this problem? We are having the same problem >> with our setup. > > I had not heard anything back from the original poster of the issue, > so I'm not sure what I can say. As you're able to reproduce the same > issue, can you provide us with some more details? Platform? Web > server? PHP version? Plugin details? > > -- > Jonathan Angliss > <jon@...> > Sure. We're running a Debian Etch system here. Apache2 version 2.2.3-4+etch8 Apache/2.2.3 (Debian) mod_auth_kerb/5.3 mod_fastcgi/2.4.2 PHP/5.2.0-8+etch15 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_perl/2.0.2 Perl/v5.8.8 configured -- resuming normal operations mysql-server-5.0 version 5.0.32-7etch10 postfix version 2.3.8-2+etch1 courier-authlib-mysql version 0.58-4+etch3 This system runs 2 gigs of memory. Plugins: 1. vlogin 2. delete_move_next 3. calendar 4. message_details 5. newmail 6. sent_subfolders 7. translate 8. listcommands 9. compatibility 10. abook_import_export 11. view_as_html 12. timeout_user 13. quicksave 14. mail_fetch 15. twc_weather 16. unsafe_image_rules 17. preview_pane 18. cookie_warning 19. askuserinfo 20. folder_synch 21. squirrel_logger 22. vkeyboard 23. change_sqlpass 24. calendar_sql_backend 25. sasql 26. abook_group_pagination 27. add_address 28. select_range 29. compose_extras 30. filters 31. squirrelspell 32. dictionary 33. get_uuencode 34. custom_charset ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: [SM-USERS] Still problems with 1.4.19 and "you must be logged in" error
by SquirrelMail Email List
::
Rate this Message:
On Thu, 18 Jun 2009, SquirrelMail Email List wrote: > > > On Thu, 18 Jun 2009, Jonathan Angliss wrote: > >> On Wed, 17 Jun 2009 15:16:37 -0700 (PDT), SquirrelMail Email List >> <sm@...> wrote: >> >>> >>> >>> On Thu, 11 Jun 2009, Jonathan Angliss wrote: >>> >>>> On Mon, 08 Jun 2009 11:30:12 +0200, Rafael Martinez >>>> <r.m.guerrero@...> wrote: >>>> >>>>> dwnek@... wrote: >>>>> [....] >>>>>> >>>>>> When I simply reconfigure httpd.conf to point to webmail-1.4.17 vice >>>>>> webmail-1.4.19 and restart the httpd service all of the above problems go >>>>>> away. >>>>>> >>>>>> I have not seen a response back to Rafael's email above yet and was >>>>>> wondering what the status of this is and if there is something that can be >>>>>> done to correct this. I am anxious to go back to 1.4.19 because of all of >>>>>> the security fixes contained in 1.4.18 including the very important fix >>>>>> regarding remote execution of server side code. >>>>>> >>>>> >>>>> Hello >>>>> >>>>> We have found a way to avoid these problems. >>>>> >>>>> We have deleted this code in src/redirect.php: >>>>> >>>>> -------------------------------------------------------------------- >>>>> if (function_exists('session_regenerate_id')) { >>>>> >>>>> session_regenerate_id(); >>>>> >>>>> // re-send session cookie so we get the right parameters on it >>>>> // (such as HTTPOnly, if necessary - PHP doesn't do this itself >>>>> >>>>> sqsetcookie(session_name(),session_id(),false,$base_uri); >>>>> } >>>>> ------------------------------------------------------------------- >>>>> >>>>> and this code in function/global.php: >>>>> >>>>> -------------------------------------------------------------------- >>>>> >>>>> sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'src'); >>>>> sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . >>>>> 'src/'); >>>>> >>>>> -------------------------------------------------------------------- >>>> >>>>> >>>>> Maybe some of the developers can explain the implications of these changes. >>>> >>>> It was in response to a security report. We try to overwrite the >>>> cookies that may already be set in the src/ directory to stop a hacker >>>> from attempting to steal information. >>>> >>>>> With these changes, users logged in squirrelmail under the upgrade will >>>>> get the "you must be logged in" error, but everything will work without >>>>> problems when they logg in again after this. >>>> >>>> I've not seen the issue myself, but then cannot say I run on a large >>>> variety of systems, so you may be coming across a combination we don't >>>> know about. >>>> >>>> What are you settings for session.auto_start in your php.ini? >>>> >>>> It's probably possibly that we should be pushing the call to the >>>> regenerate_id into src/login.php instead of src/redirect.php. >>>> >>>>> It have been a nightmare since 1.4.19 was released knowing the version >>>>> we had in production had serious security problems and not been able to >>>>> upgrade. >>>> >>>>> We are very disappointed with the null respond from developers we have >>>>> had on this issue. >>>> >>>> I did notice that your report says you're using PHP 5.2.8, Chris >>>> Hoogendyk reported a similar issue with 1.4.18, and had several >>>> platforms upgraded. Those running PHP 4.x worked, whilst the one >>>> running 5.2 failed. I'm running 5.2.0 without issues, so I'm >>>> wondering if there might be additional changes that might cause some >>>> problems, or a link between browsers too. >>>> >>>> -- >>>> Jonathan Angliss >>>> <jon@...> >>>> >>> >>> So is this the final word on this problem? We are having the same problem >>> with our setup. >> >> I had not heard anything back from the original poster of the issue, >> so I'm not sure what I can say. As you're able to reproduce the same >> issue, can you provide us with some more details? Platform? Web >> server? PHP version? Plugin details? >> >> -- >> Jonathan Angliss >> <jon@...> >> > > Sure. We're running a Debian Etch system here. > > Apache2 version 2.2.3-4+etch8 > > Apache/2.2.3 (Debian) mod_auth_kerb/5.3 mod_fastcgi/2.4.2 PHP/5.2.0-8+etch15 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_perl/2.0.2 > Perl/v5.8.8 configured -- resuming normal operations > > mysql-server-5.0 version 5.0.32-7etch10 > postfix version 2.3.8-2+etch1 > courier-authlib-mysql version 0.58-4+etch3 > > This system runs 2 gigs of memory. > > Plugins: > 1. vlogin > 2. delete_move_next > 3. calendar > 4. message_details > 5. newmail > 6. sent_subfolders > 7. translate > 8. listcommands > 9. compatibility > 10. abook_import_export > 11. view_as_html > 12. timeout_user > 13. quicksave > 14. mail_fetch > 15. twc_weather > 16. unsafe_image_rules > 17. preview_pane > 18. cookie_warning > 19. askuserinfo > 20. folder_synch > 21. squirrel_logger > 22. vkeyboard > 23. change_sqlpass > 24. calendar_sql_backend > 25. sasql > 26. abook_group_pagination > 27. add_address > 28. select_range > 29. compose_extras > 30. filters > 31. squirrelspell > 32. dictionary > 33. get_uuencode > 34. custom_charset > I figured out the problem. I had at one point upgraded my php from version 4 to version 5. In version 4 I had set "session.auto_start = 0" but in upgrade to verion 5 it got set to "session.auto_start = 1". Squirrelmail version 1.4.17 worked fine with set on but 1.14.19 did not. So set "session.auto_start = 1" in your php.ini file. Ken ------------------------------------------------------------------------------ ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: [SM-USERS] Still problems with 1.4.19 and "you must be logged in" error
by SquirrelMail Email List
::
Rate this Message:
On Mon, 29 Jun 2009, SquirrelMail Email List wrote: > > > I figured out the problem. I had at one point upgraded my php from version > 4 to version 5. In version 4 I had set "session.auto_start = 0" but in > upgrade to verion 5 it got set to "session.auto_start = 1". > > Squirrelmail version 1.4.17 worked fine with set on but 1.14.19 did not. > So set "session.auto_start = 1" in your php.ini file. > > Ken > Sorry made a mistake set "session.auto_start = 0" in your php.ini file. Ken ------------------------------------------------------------------------------ ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: Still problems with 1.4.19 and "you must be logged in" error
by Paul Lesniewski
::
Rate this Message:
No need to double-post. I am responding on the -users list here just
to say I am only going to reply further on the -devel list. > We are still having big problems with cookies under testing, before we > upgrade to 1.4.19. > > These problems are stopping us from upgrading from 1.4.17 to 1.4.19 > because with 20.000+ user of squirrelmail in our system, having to > delete all squirrelmail cookie information from their browser will not > be a practical solution (not to mention the telefon queue we would get > in the support senter when squirrelmail stops working for all of them at > the same time) > > The problem is the one explained in: > > [SM-USERS] upgrade to 1.4.18 gives "you must be logged in" error > [SM-USERS] 1.4.18 bug with src/redirect.php on php4.3.3 Show links please. I don't see anything when searching for these: http://search.gmane.org/?query=1.4.18+bug+with+src%2Fredirect.php+on+php4.3.3&author=&group=gmane.mail.squirrelmail.user&sort=date&DEFAULTOP=and&xP=Zbug%0918%09src%09redirect%09php&xFILTERS=Gmail.squirrelmail.user---A http://search.gmane.org/?query=upgrade+to+1.4.18+gives+%22you+must+be+logged+in%22+error&author=&group=gmane.mail.squirrelmail.user&sort=date&DEFAULTOP=and&xP=Zupgrad%09Zgive%09Zmust%09Zlog%09Zerror&xFILTERS=Gmail.squirrelmail.user---A > Description of the problem: > > After upgrading to 1.4.19, the only page an user will see after logging > in will be the default page with the left/right frame and folders/INBOX > information. Any click after this point will show a "you must be logged > in" error. > > The only way of getting rid of this problem is deleting all cookie > information from squirrelmail in your browser or reverting to 1.4.17. > > Deleting this code in src/redirect.php: > > -------------------------------------------------------------------- > if (function_exists('session_regenerate_id')) { > > session_regenerate_id(); > > // re-send session cookie so we get the right parameters on it > // (such as HTTPOnly, if necessary - PHP doesn't do this itself > > sqsetcookie(session_name(),session_id(),false,$base_uri); > } > -------------------------------------------------------------------- > > Or applying this patch to src/redirect.php: > > -------------------------------------------------------------------- > -- src/redirect.php (revision 13680) > +++ src/redirect.php (working copy) > @@ -80,6 +80,8 @@ > */ > if (function_exists('session_regenerate_id')) { > session_regenerate_id(); > + if (!headers_sent()) > + sqsetcookie(session_name(),session_id(),false,$base_uri); > } > > $onetimepad = OneTimePadCreate(strlen($secretkey)); > -------------------------------------------------------------------- > > Do not help and the problem is still there after these changes. And they *shouldn't* help. The second "fix" here doesn't do anything since that code should always run when headers have not been sent unless a poorly coded plugin is in use. > I think that the problem is not in src/redirect.php but in > function/global.php. This new code in 1.4.19 looks like a candidate for > being the origin of this problem, don't you think?: I can't think anything because no one has been able to tell me how to reproduce it. This code merely kills the current cookies in the browser, if any. > -------------------------------------------------------------------- > if (isset($_COOKIE[session_name()])) { > sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri); > > /* > * Make sure to kill /src and /src/ cookies, just in case there are > * some left-over or malicious ones set in user's browser. > * NB: Note that an attacker could try to plant a cookie for one > * of the /plugins/* directories. Such cookies can block > * access to certain plugin pages, but they do not influence > * or fixate the $base_uri cookie, so we don't worry about > * trying to delete all of them here. > */ > sqsetcookie(session_name(), $_COOKIE[session_name()], 1, > $base_uri . 'src'); > sqsetcookie(session_name(), $_COOKIE[session_name()], 1, > $base_uri . 'src/'); > } > > if (isset($_COOKIE['key'])) sqsetcookie('key', 'SQMTRASH', 1, > $base_uri); > > /* Make sure new session id is generated on subsequent > session_start() */ > unset($_COOKIE[session_name()]); > unset($_GET[session_name()]); > unset($_POST[session_name()]); > -------------------------------------------------------------------- > > Some tecnical information about our system: > > - RHELS 5.3, Apache/2.2.11, PHP.5.2.8 > - All traffic between the browser and apache uses SSL (port 443). > - Session data and userpref/addressbook are saved in a PostgreSQL database. > > > Do you need any more information? > How can we help to fix this problem? We need a reliable way to reproduce it. You seem to be able to reproduce it, so please explain how we can see the issue. In particular, what cookies have to be in the browser? What browser do you test with? What about other browsers? If you want to give someone on the SM team access to your test environment, one of us might be able to take a look at it there. I ran some test code that sets a cookie in /src then rebooted the browser and it works fine. SM deletes the /src cookie as it was designed to and logs in fine. Deleting all user cookies is not necessary that I know of. -- Paul Lesniewski SquirrelMail Team Please support Open Source Software by donating to SquirrelMail! http://squirrelmail.org/donations.php ------------------------------------------------------------------------------ ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: [SM-USERS] Still problems with 1.4.19 and "you must be logged in" error
by Paul Lesniewski
::
Rate this Message:
Please quote messages you are replying to. Unquoted text that belongs
to someone else should not appear in your message. > We are experiencing the same exact type problems as mentioned above by > Rafael and are also running squirrelmail 1.4.19 on RHEL 5.3 with Apache > 2.2.11 and PHP 5.2.5. I have tried commenting the whole IF statement around > line 82 in src/redirect.php and that did not work for us. I am using IE 7 > to test. > > What I am seeing is intermittent and varies as such: > 1. Sometimes when browsing to src/login.php I am redirected to the login > error page instead. > 2. When browsing to src/login.php and not redirected to the login page and > successfully log in, either both frames or one of the frames will be blank > while the other correctly displays the web content. Please provide error information for the blank frames. You should find how to diagnose blank pages if you search for it. Hint: check your logs. > 3. When browsing to src/login.php and not redirected to the login page and > successfully login, either both frames or one of the frames will display > webpage cannot be displayed while the other correctly displays the web > content. > 4. Clicking on IE's refresh sometimes successfully refreshes the faulted > frame and other times takes you to the login error page. > 5. After logging in with both frames working and just leaving the browser > sitting there with Inbox messages displayed, the left pane either goes > blank or displays webpage cannot be displayed. I think it must be occurring > during an auto refresh of the folders pane (as set in the folder options) . > > When I simply reconfigure httpd.conf to point to webmail-1.4.17 vice > webmail-1.4.19 and restart the httpd service all of the above problems go > away. So many problems sound fishy to me, but ultimately, it's something you have to help us reproduce or we can only take guesses. Please try other browsers and please provide exact details about the cookies that are in the browser when things go bad. Exact detailed steps to reproduce the issue are best. > I have not seen a response back to Rafael's email above yet and was > wondering what the status of this is and if there is something that can be > done to correct this. I am anxious to go back to 1.4.19 because of all of > the security fixes contained in 1.4.18 including the very important fix > regarding remote execution of server side code. -- Paul Lesniewski SquirrelMail Team Please support Open Source Software by donating to SquirrelMail! http://squirrelmail.org/donations.php ------------------------------------------------------------------------------ ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: [SM-USERS] Still problems with 1.4.19 and "you must be logged in" error
by Paul Lesniewski
::
Rate this Message:
On Mon, Jun 8, 2009 at 2:30 AM, Rafael Martinez<r.m.guerrero@...> wrote:
> dwnek@... wrote: > [....] >> >> When I simply reconfigure httpd.conf to point to webmail-1.4.17 vice >> webmail-1.4.19 and restart the httpd service all of the above problems go >> away. >> >> I have not seen a response back to Rafael's email above yet and was >> wondering what the status of this is and if there is something that can be >> done to correct this. I am anxious to go back to 1.4.19 because of all of >> the security fixes contained in 1.4.18 including the very important fix >> regarding remote execution of server side code. >> > > Hello > > We have found a way to avoid these problems. > > We have deleted this code in src/redirect.php: > > -------------------------------------------------------------------- > if (function_exists('session_regenerate_id')) { > > session_regenerate_id(); > > // re-send session cookie so we get the right parameters on it > // (such as HTTPOnly, if necessary - PHP doesn't do this itself > > sqsetcookie(session_name(),session_id(),false,$base_uri); > } > ------------------------------------------------------------------- > > and this code in function/global.php: > > -------------------------------------------------------------------- > > sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . 'src'); > sqsetcookie(session_name(), $_COOKIE[session_name()], 1, $base_uri . > 'src/'); > > -------------------------------------------------------------------- > > Maybe some of the developers can explain the implications of these changes. The session regeneration call prevents session fixation issues caused by malicious cookies in the browser. The call changes the session name and tells PHP to transfer the current session data to that new one. Because you store your session data in a database, I suspect this may be the problem. You should provide more details about how your session settings are configured in PHP. Try watching the session data for a given session and see if it correctly transfers the data when a regenerate is called (you can create your own test page to do that if you don't want to use SM). The sqsetcookie() calls remove any cookies in the browser that were set under the /src directory. This should also prevent abuse by malicious cookies in the browser and as far as I can see, this would not prevent proper functioning. > With these changes, users logged in squirrelmail under the upgrade will > get the "you must be logged in" error, but everything will work without > problems when they logg in again after this. > > It have been a nightmare since 1.4.19 was released knowing the version > we had in production had serious security problems and not been able to > upgrade. > > We are very disappointed with the null respond from developers we have > had on this issue. Well, since you aren't paying for the product or the support and we're doing what we can in our spare time to help you, I can't take this kind of comment as anything but discouraging of me putting in any effort into this at all. -- Paul Lesniewski SquirrelMail Team Please support Open Source Software by donating to SquirrelMail! http://squirrelmail.org/donations.php ------------------------------------------------------------------------------ ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: Still problems with 1.4.19 and "you must be logged in" error
by Maimuța Polară
::
Rate this Message:
I had the same issue as described above. The configuration is CentOS 5, Apache 2.23, PHP 5.1.6, Squirrelmail 1.4.18. I discovered that the source of my problem is the fact that when session.auto_start is true session_name() doesn't set/get the cookie name actually used for sessions. My browser is Firefox 3.5. Here is what happens when session.auto_start is true and I start with no cookies: - browser sends request for src/login.php - the server response sets two cookies, both with the same value: Set-Cookie: PHPSESSID=loa39oksk3kpojavvibmic5p57; path=/ Set-Cookie: SQMSESSID=loa39oksk3kpojavvibmic5p57; path=/; HttpOnly - browser sends username and password to src/redirect.php; it sends back both cookies Cookie: PHPSESSID=loa39oksk3kpojavvibmic5p57; SQMSESSID=loa39oksk3kpojavvibmic5p57 - the server response, a redirect to src/webmail.php (so I was authenticated successfully), contains multiple Set-Cookie, the final cookie being created by session_regenerate_id(): Set-Cookie: SQMSESSID=loa39oksk3kpojavvibmic5p57; path=/; HttpOnly [the above line repeated a few times] Set-Cookie: squirrelmail_language=en_US; expires=Sat, 01-Aug-2009 14:08:02 GMT; path=/; HttpOnly Set-Cookie: SQMSESSID=po918qludujgo9hmrsj1pj5h23; path=/ Set-Cookie: SQMSESSID=po918qludujgo9hmrsj1pj5h23; path=/; HttpOnly [the above line repeated a few times] Set-Cookie: key=ptY6xwMHCNY%3D; path=/; HttpOnly Set-Cookie: SQMSESSID=po918qludujgo9hmrsj1pj5h23; path=/; HttpOnly [the above line repeated a few times] - the browser requests src/webmail.php, sending back the old session id in PHPSESSID and the new one in SQMSESSID: Cookie: PHPSESSID=loa39oksk3kpojavvibmic5p57; SQMSESSID=po918qludujgo9hmrsj1pj5h23; squirrelmail_language=en_US; key=ptY6xwMHCNY%3D - server response tells me that I need to log in first and sends back the old session id: Set-Cookie: SQMSESSID=loa39oksk3kpojavvibmic5p57; path=/; HttpOnly The on disk session files are OK: - the old session, with id loa39oksk3kpojavvibmic5p57, has the usual content for unauthenticated users - the new session, with id po918qludujgo9hmrsj1pj5h23, has the content for authenticated users I started to suspect that php gets the session id from the PHPSESSID cookie and ignores the SQMSESSID cookie. I searched if this is a known issue and I found that others had the same issue: http://bugs.php.net/bug.php?id=35233 https://bugzilla.wikimedia.org/show_bug.cgi?id=3990 In my case the solution was to either set session.auto_start to false or to make in functions/global.php and include/validate.php the same code change as in MediaWiki, i.e. don't set session_name if session.auto_start is true. I hope that helps you to reproduce the problem and make a fix. |
|
|
Re: Still problems with 1.4.19 and "you must be logged in" error
by Michael Peddemors-2
::
Rate this Message:
Paul, just a quick note.. we did see some problems ourselves during our last
updates of a similar nature, however our session/cookie stuff has chnaged enough that we cannot directly provide a patch, but this is something that you might want to watch for on upcoming releases, ie some kind of mechanism to change session names on each upgrade. In large ISP environments, it is a big pain to run into the situation where they have to clear old cookies, and that might be a safety to avoid any issues surrounding sessions especially as I expect that more work will be done in that area.. In the mean time, for this person.. he could simply do this himself it looks like in this case, could he not? (As a work around until the underlying issue is examined?) Oh, just reading the followup post and I see that the auto_start would preclude SQ doing that anyways. :) He 'could' change the global name in his PHP.INI as well .. hehehe.. But as pointed out, this is more a configuration issue, and a problem with session naming in general.. Maybe a FAQ item covering PHP Session settings might be the way to go. (Unless there already is one :) On July 1, 2009, Paul Lesniewski wrote: > No need to double-post. I am responding on the -users list here just > to say I am only going to reply further on the -devel list. > > > We are still having big problems with cookies under testing, before we > > upgrade to 1.4.19. > > > > These problems are stopping us from upgrading from 1.4.17 to 1.4.19 > > because with 20.000+ user of squirrelmail in our system, having to > > delete all squirrelmail cookie information from their browser will not > > be a practical solution (not to mention the telefon queue we would get > > in the support senter when squirrelmail stops working for all of them at > > the same time) -- "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. ------------------------------------------------------------------------------ ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: Still problems with 1.4.19 and "you must be logged in" error
by Paul Lesniewski
::
Rate this Message:
>>> Description of the problem:
>>> >>> After upgrading to 1.4.19, the only page an user will see after logging >>> in will be the default page with the left/right frame and folders/INBOX >>> information. Any click after this point will show a "you must be logged >>> in" error. >>> >>> The only way of getting rid of this problem is deleting all cookie >>> information from squirrelmail in your browser or reverting to 1.4.17. >> [...] >>> >>> Some tecnical information about our system: >>> >>> - RHELS 5.3, Apache/2.2.11, PHP.5.2.8 >>> - All traffic between the browser and apache uses SSL (port 443). >>> - Session data and userpref/addressbook are saved in a PostgreSQL >>> database. >>> >>> >>> Do you need any more information? >>> How can we help to fix this problem? >> >> We need a reliable way to reproduce it. You seem to be able to >> reproduce it, so please explain how we can see the issue. In >> particular, what cookies have to be in the browser? What browser do >> you test with? What about other browsers? If you want to give >> someone on the SM team access to your test environment, one of us >> might be able to take a look at it there. >> >> > > I had the same issue as described above. The configuration is CentOS 5, > Apache 2.23, PHP 5.1.6, Squirrelmail 1.4.18. I discovered that the source of > my problem is the fact that when session.auto_start is true session_name() > doesn't set/get the cookie name actually used for sessions. SM 1.4.x is not compatible with session.auto_start. If you run configtest after you configure SM, you'd see that. This is not a bug and is the way the product works. The OP of this issue didn't state if that was his problem, and if not, it might have something to do with storing session data in a database. > My browser is Firefox 3.5. Here is what happens when session.auto_start is > true and I start with no cookies: > - browser sends request for src/login.php > - the server response sets two cookies, both with the same value: > > Set-Cookie: PHPSESSID=loa39oksk3kpojavvibmic5p57; path=/ > Set-Cookie: SQMSESSID=loa39oksk3kpojavvibmic5p57; path=/; HttpOnly > > - browser sends username and password to src/redirect.php; it sends back > both cookies > > Cookie: PHPSESSID=loa39oksk3kpojavvibmic5p57; > SQMSESSID=loa39oksk3kpojavvibmic5p57 > > - the server response, a redirect to src/webmail.php (so I was authenticated > successfully), contains multiple Set-Cookie, the final cookie being created > by session_regenerate_id(): > > Set-Cookie: SQMSESSID=loa39oksk3kpojavvibmic5p57; path=/; HttpOnly > [the above line repeated a few times] > Set-Cookie: squirrelmail_language=en_US; expires=Sat, 01-Aug-2009 14:08:02 > GMT; path=/; HttpOnly > Set-Cookie: SQMSESSID=po918qludujgo9hmrsj1pj5h23; path=/ > Set-Cookie: SQMSESSID=po918qludujgo9hmrsj1pj5h23; path=/; HttpOnly > [the above line repeated a few times] > Set-Cookie: key=ptY6xwMHCNY%3D; path=/; HttpOnly > Set-Cookie: SQMSESSID=po918qludujgo9hmrsj1pj5h23; path=/; HttpOnly > [the above line repeated a few times] > > - the browser requests src/webmail.php, sending back the old session id in > PHPSESSID and the new one in SQMSESSID: > > Cookie: PHPSESSID=loa39oksk3kpojavvibmic5p57; > SQMSESSID=po918qludujgo9hmrsj1pj5h23; squirrelmail_language=en_US; > key=ptY6xwMHCNY%3D > > - server response tells me that I need to log in first and sends back the > old session id: > Set-Cookie: SQMSESSID=loa39oksk3kpojavvibmic5p57; path=/; HttpOnly > > The on disk session files are OK: > - the old session, with id loa39oksk3kpojavvibmic5p57, has the usual content > for unauthenticated users > - the new session, with id po918qludujgo9hmrsj1pj5h23, has the content for > authenticated users > > I started to suspect that php gets the session id from the PHPSESSID cookie > and ignores the SQMSESSID cookie. I searched if this is a known issue and I > found that others had the same issue: > http://bugs.php.net/bug.php?id=35233 > https://bugzilla.wikimedia.org/show_bug.cgi?id=3990 > > In my case the solution was to either set session.auto_start to false or to > make in functions/global.php and include/validate.php the same code change > as in MediaWiki, i.e. don't set session_name if session.auto_start is true. > > I hope that helps you to reproduce the problem and make a fix. No "fix" for this is intended. Please run src/configtest.php before you try to use SquirrelMail. -- Paul Lesniewski SquirrelMail Team Please support Open Source Software by donating to SquirrelMail! http://squirrelmail.org/donations.php ------------------------------------------------------------------------------ ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: Still problems with 1.4.19 and "you must be logged in" error
by Maimuța Polară
::
Rate this Message:
On Thu, Jul 2, 2009 at 7:27 PM, Paul Lesniewski wrote:
> > SM 1.4.x is not compatible with session.auto_start. If you run > configtest after you configure SM, you'd see that. This is not a bug > and is the way the product works. For us, simple users of squirrelmail and admins having to install and configure it, this incompatibility is acknowledged unfortunately only in the last version, 14.19, released just a few weeks ago. > The OP of this issue didn't state > if that was his problem, and if not, it might have something to do > with storing session data in a database. If the only changes he made were the ones described, then I suspect that he had session.auto_start enabled because the problem was solved by deleting the session_regenerate_id() call. > No "fix" for this is intended. Please run src/configtest.php before > you try to use SquirrelMail. Please consider the fact that some of us use the squirrelmail package coming with the distribution we have, we don't install it from scratch. Until today I haven't knew about configtest.php. On the few systems where I installed and configured squirrelmail I just added the configuration lines I needed into config_local.php and squirrelmail worked. If the OP had indeed session.auto_start enabled, it looks like he did not run configtest.php either. It looks like the other poster, Ken, who said that he solved the problem by disabling session auto start, did not run configtest.php either. I suppose that you, as a developer of squirrelmail, would like to have every person installing and configuring squirrelmail run configtest.php before using it, but the reality shows that not all people do that. We want to complete our tasks in the shortest time possible, which means we sometimes don't start by reading the docs so we don't know about configtest.php. We have the tendency to hope that all is required to make squirrelmail work in simple setups is to add or change a few lines in the squirrelmail configuration. I think it would help us, the users of squirrelmail, if a "fix" (not changing the session name) or an improvement (warn in error_log if session auto start is enabled) is implemented eventually. The "fix" would just make squirrelmail work, no matter what is the status of session auto start (I acknowledge I could be missing something here), while warning about the incompatibility will give us a fast hint about what's wrong since we are used to look into error_log when something is not working. The point I'm trying to make is that the "fix" or improvement is so small that is worth making it since less people would be affected by this incompatibility. Thank you! ------------------------------------------------------------------------------ ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
|
|
Re: Still problems with 1.4.19 and "you must be logged in" error
by Paul Lesniewski
::
Rate this Message:
On 7/2/09, Maimuța Polară <maimuta.polara@...> wrote:
> On Thu, Jul 2, 2009 at 7:27 PM, Paul Lesniewski wrote: >> >> SM 1.4.x is not compatible with session.auto_start. If you run >> configtest after you configure SM, you'd see that. This is not a bug >> and is the way the product works. > > For us, simple users of squirrelmail and admins having to install and > configure it, this incompatibility is acknowledged unfortunately only > in the last version, 14.19, released just a few weeks ago. > >> The OP of this issue didn't state >> if that was his problem, and if not, it might have something to do >> with storing session data in a database. > > If the only changes he made were the ones described, then I suspect > that he had session.auto_start enabled because the problem was solved > by deleting the session_regenerate_id() call. > >> No "fix" for this is intended. Please run src/configtest.php before >> you try to use SquirrelMail. > > Please consider the fact that some of us use the squirrelmail package > coming with the distribution we have, we don't install it from > scratch. Until today I haven't knew about configtest.php. On the few > systems where I installed and configured squirrelmail I just added the > configuration lines I needed into config_local.php and squirrelmail > worked. > > If the OP had indeed session.auto_start enabled, it looks like he did > not run configtest.php either. It looks like the other poster, Ken, > who said that he solved the problem by disabling session auto start, > did not run configtest.php either. > > I suppose that you, as a developer of squirrelmail, would like to have > every person installing and configuring squirrelmail run > configtest.php before using it, but the reality shows that not all > people do that. We want to complete our tasks in the shortest time > possible, which means we sometimes don't start by reading the docs so > we don't know about configtest.php. We have the tendency to hope that > all is required to make squirrelmail work in simple setups is to add > or change a few lines in the squirrelmail configuration. I think the posting guidelines mention configtest.php. Perhaps many admins want to spend as little time on their systems as possible, but I consider it a profound lack of awareness, compassion and respect when people come here asking questions without reading, understanding and following the posting guidelines. Those of you coming here for a quick fix think we here don't also value our time like you do? > I think it would help us, the users of squirrelmail, if a "fix" (not > changing the session name) or an improvement (warn in error_log if > session auto start is enabled) is implemented eventually. The "fix" > would just make squirrelmail work, no matter what is the status of > session auto start (I acknowledge I could be missing something here), Yes, you're missing the great complexity involved. Our development code works either way, but 1.4.x won't be fixed in that manner. However, your point is well-taken and I have instead implemented a section in the startup code that will check for incompatible PHP settings and flat-out stop (refuse to run) until said settings are fixed by the admin. > while warning about the incompatibility will give us a fast hint about > what's wrong since we are used to look into error_log when something > is not working. > > The point I'm trying to make is that the "fix" or improvement is so > small that is worth making it since less people would be affected by > this incompatibility. > > Thank you! Thanks for your thoughts. -- Paul Lesniewski SquirrelMail Team Please support Open Source Software by donating to SquirrelMail! http://squirrelmail.org/donations.php ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ----- squirrelmail-devel mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-devel@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel |
| Free embeddable forum powered by Nabble | Forum Help |
