Andreas,
> ok, here we are with the cookies.
Thanks for helping us!
> just login page:
> after login page load:
>
> SQMSESSID
> 600f0903f14941db0d8d7a8a6b81b1ff
>
> before regenerate:
>
> SQMSESSID
> 600f0903f14941db0d8d7a8a6b81b1ff
>
> i.e., before regenerate call, sessionid keeps the same.
As expected. Surely this is all normal.
> second try:
> (exit immed. after regernate)
>
> after login page load:
>
> SQMSESSID
> 080de59be5b358b9b0993b95cf3870f8
>
> after regenerate:
>
> SQMSESSID
> 7098cd4e23d8b90e0ad4d5dfdf2c186a
> squirrelmail_language
> de_DE
>
> so, the regenerate alters sessionid despite of an valid login!
This is as expected, too. All is well so far. The one thing to check
here, though, is if the session data moved to the correct place at the
same time. Can you try this again and look at your session files to
see if the content went into the correct one? The session files are
in the location specified by session_save_path in php.ini....
typically something like /var/lib/php/session
> Third try
> (exit imm. after sessio_write_close)
>
> after login page load:
>
> SQMSESSID
> 6a76ecbe957184ad7dc8563d0e950da4
>
> after session_write_close():
> SQMSESSID
> 0078fc5c6ed3a6faa756a85efed62358
> squirrelmail_language
> de_DE
> key
> KouVaayIPl81TQ%3D%3D
>
> (that's just to verify the second try).
>
> Hope this gets you further.
Well, it all looks correct here - no explanation why the session would
fail. Perhaps the session data not moving to the right file? If it
is, the next step would be to put an exit statement near the beginning
of /src/webmail.php and see both what the browser's cookie is at that
time and what is in the corresponding session data file. If you do
this at the top of webmail.php, keep in mind, the PHP session won't be
started at that point (that's OK).
If everything looks good there, check that this page request is the
one that is failing in the first place. Go to include/validate.php,
add this code at line 56, before the is_logged_in() call:
if (stristr($_SERVER['PHP_SELF'], '/src/webmail.php')) {
sm_print_r($_COOKIE, $_SESSION);
exit;
}
If you find a setting for "is_logged_in" therein, move this code to
after the is_logged_in() call and make sure it appears again - in
which case this is not where the process is failing (which would be
even more perplexing).
If the above does prove to be where the session is failing, does that
session output show anything at all? Is it just empty? How does the
cookie output compare to what's on your browser side? What about the
ID? The session data file? We might need to check in
sqsession_start() in functions/global.php when webmail.php is loading
if nothing here shows the problem.
Also, do you have session.auto_start turned off? You can show the
output of src/configtest.php too...
> I will simply comment out the session_regenerate_id() call, as long as I
> use PHP 4
>
> squirrelmail_language
> de_DE
> Paul Lesniewski schrieb:
>> On Thu, May 14, 2009 at 5:44 AM, Andreas Vogt <a_vogt@xxxxxxx> wrote:
>>>
>>> (SM 1.4.18, PHP 4.3.3)
>>>
>>> Hi,
>>>
>>> after updating to 1.4.18
>>> all users are immediatley logged out afters login.
>>> SM just asks the IMAP server for INBOX, then the SM logs out.
>>>
>>> I could break this issue down to
>>> line 82 in src/redirect.php
>>> session_regenerate_id();
>>>
>>> As stated in new redirect.php:
>>> * NB: session_regenerate_id() was added in PHP 4.3.2 (and new session
>>>
>>> * cookie is only sent out in this call as of PHP 4.3.3), but PHP 4
>>>
>>> * is not vulnerable to session fixation problems in SquirrelMail
>>>
>>> Obviuosly, PHP 4.3.3. got some problems with
>>> session_regenerate_id();
>>
>> Ugh, yes indeed it looks like it. Can you take snapshots of the
>> SquirrelMail cookies in your browser for each step? --
>>
>> - after login page loads
>> - just before the regenerate() call (put an exit; call before it)
>> - just after the regenerate() call (put an exit; call after it)
>> - after the session_write_close() call but before the
>> header('Location') redirect
>> (put an exit; call between the two) - should be around line 181
>>
>> It might also be helpful to see the contents of $_COOKIE under each of
>> those steps.
>>
>>> I tried to disable line 82. After this, everything works great, but I
>>> don't know, what security problems I will get now (beside of having PHP
>>> 4.3.3 ;) )
>>
>> Probably none - it seems to be mostly a PHP 5 issue.
>>
>>> best regards and thank you for your great job!
>>
--
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
