>>>>> I have 3 very similar servers with different domains running squirrelmail. >>>>> >>>>> I updated all three from 1.4.10a to 1.4.18 this morning. >>>>> >>>>> 2 of them went perfectly smoothly. I untarred the release into the ssl >>>>> directory. I copied the config.php file from the older release to the >>>>> newer release. I connected from FireFox to make sure the existing >>>>> install was working. Then I removed a symlink "mail" that pointed to >>>>> squirrelmail-1.4.10a and recreated it pointing to squirrelmail-1.4.18. >>>>> Then I connected from FireFox to make sure the new install was working. >>>>> >>>>> So, the configured smdata and smattach are unchanged. The same Apache >>>>> and php are running and the config file still points to the same place >>>>> which still has ownership and write access for user http. >>>>> >>>>> On the third server, following exactly the same procedures, when I tried >>>>> to connect to the new 1.4.18, it took me from the login page to an error >>>>> page saying "you must be logged in to access this page". Since I have >>>>> many users depending on this, I immediately reverted the symlink back to >>>>> 1.4.10a. My attempt to connect then worked. >>>>> >>>>> I tried going to my FireFox preferences and deleting the squirrelmail >>>>> cookies from all three domains. Then I tried going to 1.4.18 on the 3rd >>>>> domain. Same error. >>>>> >>>>> There are two differences that I can think of for the servers. The first >>>>> 2 are back on php 4, because they have some legacy code that needs to be >>>>> fixed in some other applications. The 3rd server, which gives me this >>>>> error, is on php 5. >>>>> >>>> http://news.gmane.org/find-root.php?message_id=%3c267a7b0ff79cca0e638839aeda61f387.squirrel%40intraweb.gaia.de%3e >>>> >>>> Please state the exact PHP version and try the suggested debug actions >>>> in that thread to help us understand what is going on. >>>> >>> Sorry, I should have just included the configtest.php output originally. >>> I have put the output below for the server that has the problems and for >>> one of the servers that works. >>> >>> Also, as per the thread you mentioned above, I disabled line 82 in >>> src/redirect.php (enclosed the whole if statement in comment from 81 to >>> 83) and everything worked fine. I re-enabled line 82, and again got the >>> original error I was asking about. Can you reconfirm that you did not switch the configtest output from the working and non-working versions? Previously it appeared that PHP 4 might be broken, but you say PHP 5 is on the broken server? It may also be instructive if you can try out 1.5.2SVN (snapshot tarballs are available on our download page), to see if that fails too. >>> When login screen displays, SQMSESSID = 874b11ec73130b8dd16f495cddb76758. >>> >>> With exit just before line 82, SQMSESSID = 874b11ec73130b8dd16f495cddb76758. >>> >>> Switched exit to just after line 82, put my cursor in the url field at >>> the top of firefox and hit return to re-enter src/redirect.php, got the >>> same error, and SQMSESSID = 874b11ec73130b8dd16f495cddb76758. Those are >>> all identical. Are these the values in the cookies in your browser? Or did you print anything out from the server side (such as sm_print_r($_COOKIE); )? It can also be helpful if you can look at the actual session data files - they are in the directory pointed to by the session_save_path in php.ini, sometimes something like /var/lib/php/session.... you can then watch the contents of the session file that corresponds to your session ID and see if it has the right session data in it or not. >>> So, is that the information you were looking for? I didn't see any >>> response yet from Andreas Vogt on that thread. >>> >>> Let me know if there is something else you would like me to do. >> >> After seeing Andreas' response shortly after mine, I doubted my >> procedure of doing it all in one sequence and just putting my cursor in >> the url line and making it refresh. Right, thanks. Before, it looked like the ID wasn't even being regenerated, but... >> So, if I have the exit right after line 82, and start from scratch >> (deleting cookies first), >> show login screen, SQMSESSID = 984a64f6664c8a6f7b1e4c848a344560 >> enter login & exit after line 82, SQMSESSID = >> 3c49aa620554227bb2c5a29949e74515 That's how it should look. You might look at the session data files to see if the data is in the right one (per above). >> In addition, the cookie first says send for secure sessions only, and >> then after it changes, it says for any kind of session. Thanks, PHP. It sends its own cookie in this case, apparently ignoring the parameters on the first one. In fact, this might be the crux of the whole problem - whether or not PHP re-sends the cookie, the cookie parameters it uses, how these things change per PHP version, etc. I don't know if we can avoid this, but I'll look into it. >> Ooooh, here's a totally weird piece of information -- I just tried >> Safari at someone else's suggestion. It's dialog for dealing with the >> expired certificate is different, and it sets a several options >> regarding always trusting the expired certificate. Anyway, it worked. >> With line 82 active and no exits added to the code (in other words with >> squirrelmail-1.4.18 as released), Safari works. Very odd. So it might be that PHP is sending a cookie back, but it's slightly different than the original... and Safari doesn't care, but Firefox does. Just conjecture at this point... >> Now I'm not sure where this is all going. > > OK. Based on the fact that Safari worked and that the certificate issues > were addressed slightly differently in Safari, I went back to FireFox > and opened up the details on how it was handling that certificate. I > removed the defaults and made it allow everything. I think the only > difference was allowing popups for the site. But, in any case, it now > works!! uhhh....? > So, in my case, it seems to be some weird interaction between the > expired certificate, how that is being handled, and the session cookie. > Popups? Where does that come in? It shouldn't have anything to do with the certificate. Once it's accepted, traffic can move over SSL between browser and server, and its status shouldn't matter, expired or not. I don't quite know what you mean by allowing popups in the context of the SSL certificate. But popups in general shouldn't be an issue, either, since there is no popup in this case. So far, the best guess I have is as above - the re-sent cookie differs just enough from the original to cause problems in some cases. -- Paul Lesniewski SquirrelMail Team Please support Open Source Software by donating to SquirrelMail! http://squirrelmail.org/donate_paul_lesniewski.php ------------------------------------------------------------------------------ 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-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
