Re: upgrade to 1.4.18 gives "you must be logged in" error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Chris Hoogendyk wrote:
> Chris Hoogendyk wrote:
>   
>> Paul Lesniewski wrote:
>>
>>     
>>> On Fri, May 15, 2009 at 10:56 AM, Chris Hoogendyk
>>> <hoogendyk@xxxxxxxxxxxxx> 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.
>>
>> 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.
>>
>> 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.
>
> 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
>
> In addition, the cookie first says send for secure sessions only, and 
> then after it changes, it says for any kind of session.
>
> 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.
>
> 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!!

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?


-- 
---------------

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


[Index of Archives]     [Video For Linux]     [Yosemite News]     [Yosemite Photos]     [gtk]     [KDE]     [Cyrus SASL]     [Gimp on Windows]     [Steve's Art]     [Webcams]

  Powered by Linux