On Sun, Dec 15, 2002 at 05:15:52PM -0600, Jonathan Angliss wrote:
> Hello Matthias, On Sunday, December 15, 2002, Matthias Hensler
> wrote...
>
> > After upgrading from PHP 4.2.2 to 4.3.0RC3 I discovered a strange
> > problem from which I am not sure if it is a bug in the
> > development-tree or in Squirrelmail (that is because I don't
> > understand the session-handling in SM in detail :-)
>
> I've noticed a few people mentioning session issues with 4.3.0rc3...
> please note that is a release candidate, and still under
> development, so there are possibilities that it is still buggy.
Yes, I know that. Thats because I am asking if it is just a bug in
4.3.0rc3 or a problem with the session-management in SM which worked
fine before.
> > This is what happens: trying to login the first time will always
> > fail. Login in the second time causes no problems and you can work
> > like usual. If you logout and try to login again its the same thing
> > (first try fails, second works).
>
> > The problem is session-related. I played around a bit with the
> > source and found this out:
>
> > If the login-site is opened the first time PHP inserts a session-id
> > after the <form> (PHP was compiled with "--enable-trans-sid").
>
> You can turn off trans-sid in the php.ini file, but I'll see from
> what you say if we can work around it :)
>
> > "/src/login.php": [...] <form ACTION="redirect.php"
> > METHOD="POST"><input type="hidden" name="SQMSESSID"
> > value="fa59ce79ca8b805c37d43bd0bc79d7f8" /> [...]
>
> > Login in with the correct username and password while submitting
> > that session-id will always fail. A reload causes the inserted
> > session-id to go away.
>
> Can you open src/global.php and src/validate.php and find the line
> which says:
>
> ini_set('session.name' , 'SQMSESSID');
>
> It's right near the top on both files. Try commenting it out, and
> attempting a login again.
No, that doesn't change anything. Exactly the same problem like before.
> > I was able to work around this, by removing
>
> > setcookie(session_name(), '', time() - 5,
> > $cookie_params['path'], $cookie_params['domain']);
>
> > in src/global.php (lines 150+151), function sqsession_destroy().
>
>
> > I am not sure what happens here. First SM creates a session, deletes
> > the superglobal $_SESSION and destroys the session again. If it
> > would stop here everything would be fine.
>
> Do you have session.auto_start set to 1? The function you mention
> was an attempt at fixing cross session issues where multiple people
> logging in from the same browser would result in the sessions
> becoming merged if a person didn't log out. I have updated this
> function in 1.2.11[cvs] so it should actually work now. The problem
> being, is if you have session.auto_start set to 1, a session is
> started with a default session name, while any point after that, we
> try to find a different session name. This would result in session
> issues and the login problem you might be experiencing.
Sorry, but session.auto_start is disabled here.
> > But setting this cookie seems to trigger the insertion of a
> > transparent session id by PHP.
>
> I think it might have something to do with the way I wrote it
> originally. I've altered it recently, and it'll never start a
> session in the sqsession_destroy() function if it doesn't detect a
> session, where as last time, it'd start a session, then destroy it.
>
> > The problem is reproduceable by just opening the src/login.php in a
> > view-source window of mozilla and pressing reload again and again:
> > the first time there is the hidden "SQMSESSID" inserted, and the
> > next time not. If I change the the cookie-time to time()-5000 the
> > hidden ID never goes away.
>
> SQMSESSID is the name we decided on a new session name to stop an
> interaction with other PHP applications such as gallery. If you
> don't find you have conflicts with them, just comment out the
> ini_set('session.name' , 'SQMSESSID'); from src/global.php and
> src/validate.php
We don't have conflicts with other PHP applications, but nevertheless,
changing the name for the session, or using the default one doesn't fix
the problem.
> > I cannot tell if the problem was introduced with PHP 4.3.0RC3, since
> > I had enough problems with 4.2.3 and waited a long time before
> > upgrading to a newer version (although necessary because of some of
> > the security related things in 4.2.2).
>
> Again I point out, 4.3.0RC3 is a release candidate at the moment,
> meaning they are probably still doing some serious work on it, but
> try the suggested options I mention, if you still get issues, let us
> know, and I'll send you the updated sqsession_destroy() code, or you
> can just take a look at the CVS for that file.
So far only disabling the setcookie-part helps. Maybe it is time to
inform the PHP developers?
Matthias
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
--
squirrelmail-users mailing list
List Address: [EMAIL PROTECTED]
List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=2995
List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
