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: > > upgrade to 1.4.18 gives "you must be logged in" error > 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-users mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx List archives: http://news.gmane.org/gmane.mail.squirrelmail.user List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
