A strange effect with user login

Monday 03 March 2003 5:00:28 am

With ezp3-rc2 I observe a strange effect which I had not faced before. I could not trace the source of this, so I like to post it here in the hope for some hint:

When logging in to a non-public site with RequireUserLogin-flag set, it sometimes (I still do not know under which circumstances) happens that a user's first attempt to login with VALID (!!) credentials for the site results in a shadow-login to the PUBLIC site. However, the user receives another login screen without any warning or so for the non-public site he wants to access. If he enters his credentials again, he gets in as expected.

I found that the effect occurs when ezp runs php-sessions.

Any ideas ?

Thursday 06 March 2003 1:18:10 am

> > With ezp3-rc2 I observe a strange effect which I had not
> > faced before. I could not trace the source of this, so I
> > like to post it here in the hope for some hint:
> >
> > When logging in to a non-public site with
> > RequireUserLogin-flag set, it sometimes (I still do not
> know
> > under which circumstances) happens that a user's first
> > attempt to login with VALID (!!) credentials for the
> site
> > results in a shadow-login to the PUBLIC site. However,
> the
> > user receives another login screen without any warning or
> so
> > for the non-public site he wants to access. If he enters
> his
> > credentials again, he gets in as expected.
> >
> > I found that the effect occurs when ezp runs
> php-sessions.
> >
> >
> > Any ideas ?
>
> Additional findings:
>
> Effect occurs once each time you close & reopen your
> webbrowser.
>
> As far as I see, the effect of a "shadow login" is somehow
> related to php session management. I have cookie-less
> sessions enabled in my php.ini. Thus, ezp sessions won't
> place session cookies and anonymous users are confronted
> with session-id's added to template hrefs on the first page
> request in a new browser window.
>
> However, after the first page reload in a -- NEW -- browser
> window, the PHPSESSID dissapears from uri-requests and I
> wonder where it goes ??!!
>
> Once the PHPSESSID has gone, the shadow login problem
> vanishes, too. Any clue ?

Ok, this one is clarified:

If you have more than one domain on your system, php session manager sets an individual session cookie for each of these domains unless you specify otherwise in php.ini.

Now, on the first page load, the cookie is set, but cannot be immediately used as session-id container yet. Therefore, php uses PHP-session ids appended to your html til the cookie value becomes available to track a session.

If you have a link from domain1 to domain2 in one of your templates and a user presses this link immediately after having requested the page, the link will inevitably carry the php-sessionid of domain 1.
If the link to domain2 with a phpsession-id of domain1 is a link that opens a login screen, the user who logs in will NOT be logged in to domain2, but to domain1 instead, since the users login session-id belongs to domain1.

This is unwelcome and can only be resolved if you declare your session cookie valid for ALL domains. However, in order to support login-policy-restrictions in such an environment, you need to set explicit user-login-siteaccess1, user-login-siteaccess2 policies. And, most of all, you will need a patched version of ezp's index.php-file, otherwise users with all-domain session cookies will be allowed to login to all daomains even if they are denied by siteaccess-rules.