Paul Lesniewski wrote: >>>>>> 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. Just to clarify and fill out some details. In Firefox, if I click on the icon next to the url field at the top, it brings up the dialog titled "Page Info - https://mydomain/mail/...";. If I click on the permissions tab, I then see 4 groups of options. Originally, they were all set to "Use Default", and the result was that Load Images was allowed, Open Pop-up Windows was blocked, Set Cookies was allowed, and Install Extensions or Themes was blocked. I clicked off the Use Default on the first three and set the Open Pop-up Windows to allow. That is the only change I made. Previously, the dialog had come up with the Security tab selected, when the certificate expired, I simply asked Firefox to set an exception for it and accept it. In Safari (which I don't normally use, so I had not encountered the expired certificate yet), when the objection came up to the expired certificate, I clicked on the button to Show Certificate, then there was a triangle icon down to the left that opened up a section of the window for Trust. In that section, there was a popup that initially said Use System Defaults. I changed that to Always Trust, and it popped the other options to Always Trust. Then I clicked Continue. Safari worked, and that is what triggered me to go back to Firefox and change all the options to Allow as described above. I don't know how or why that interacts with what is being done with the cookie/session to make it work rather than decide that I am not logged in. It would be interesting to hear from Andreas as to whether he might have a self signed certificate that he long ago made an exception for in Firefox and has forgotten about. It could be that the "Always Trust" has details beyond what is explicit in the dialog in terms of options. Then, if the cookie varies slightly, Firefox gets its nose out of joint. Anyway, unless we come up with a fix in php or squirrelmail, we are going to hold off on the upgrade and put renewing our certificate on the front burner. A problem like this just becomes a real pain when you have to deal with a lot of users. Monday, we will hit up the Windows support guy and have him try out IE. -- --------------- Chris Hoogendyk - O__ ---- Systems Administrator c/ /'_ --- Biology & Geology Departments (*) \(*) -- 140 Morrill Science Center ~~~~~~~~~~ - University of Massachusetts, Amherst <hoogendyk@xxxxxxxxxxxxx> --------------- Erdös 4 ------------------------------------------------------------------------------ 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
