[Phpgroupware-developers] Re: phpgw's handling of cookies

[totschnig . michael]

"Patrick Walsh (mr_e)" <address@hidden> a écrit:

>> This means that this was introduced for sitemgr, if I understand
>> right. Wouldn't it be possible to proceed differently so that when a
>> user goes from phpgroupware to sitemgr we set the same cookie a second
>> time, with the path set for the sitemgr installation, and if we want
>> to go from sitemgr to phpgroupware we do the same thing? There might
>> me two other advantages to this approach:
>> - You could even configure the sitemgr-site with a virtual host that
>> is in another domain than sitemgr.
>> - You could enforce that all switches between phpgroupware to sitemgr-site
>> are either by design (and than we share the same session) or
>> accidental (and than we create different sessions). What I mean is
>> that you might want to browse the public site as an anonymous user,
>> and in the same time be logged in as a user. And you might prefer to
>> prevent completely that anonymous visitors to the public website log
>> into phpgroupware.
>
>     This does make a certain amount of sense.  It means that two session
> cookies would be set everytime there is a new session.  

my ideas was that the second cookie would not be set at the beginning
of a new session, but only at the moment where a user
switches from phpgroupware to sitemgr-site or the other way round.
I.e. two cases with two subcases:
- a user logs into phpgroupware and the cookie is set for the exact
host and the exact path of the phpgroupware installation. If he clicks
on sitemgr-link, we reproduce the same session cookies with the host and the
path of the sitemgr-site installation. If he goes to sitemgr-site
directly (by typing the URL in his browser a selecting a bookmark), a
new independent session is created for the anonymous user.
- a user goes to sitemgr-site. A session for user anonymous is created
and the cookie is set for host and path of sitemgr-site. If the user
than goes to the phpgroupware URL directly the session cookies is not
transmitted, and he has to login. If we want to link from sitemgr-site
to phpgroupware, i.e. give the anonymous user access to some
application, we do not link directly, but pass through a gateweay (in
a similar way as sitemgr-site does) we reproduce the cookies and
redirect to phpgroupware.

> It also means fundamental changes to the sessions class in the API
> specifically for one app.  I'll defer to the phpgw leaders who work
> actively on the API.

I am not sure if the changes were so fundamental. If I am not
mistaken, the crucial part in the API would be to call setcookie with
different values for sitemgr-site. The reproduction of the session
cookie do not have to be done in the API, but could be done in
sitemgr-link and the sitemgr-sites redirection function. But maybe I
am missing something.

>
>>>     Suppose each site on your machine could have a unique identifier.
>>> Suppose all of the cookies specific to a given install were named
>>> name-identifier, such as session-0, session-1, etc.  You would still share
>>> the PHP4 session, but the phpgw session info, credentials, etc., would be
>>> separated.  Does that sound like it could work?
>> 
>> This makes sense to me. Would it mean that in header.inc.php we add a
>> field domain_identifier to $GLOBALS['phpgw_domain']['default'] and use
>> this in the session classes when constructing the cookies?
>
>     Yes, something like that is exactly what I mean.  The info is probably
> better kept in the db instead of header.inc.php so that it can be changed
> from the setup screens.  Otherwise, this is what I was suggesting.
>
>     Again, those that are playing with the API: ralfbecker, seek3r, ceb, and
> I'm not sure who else right now, should have some input on this.

I really wish this issue could be addressed quickly. I think
phpgroupware should not create hurdens for being used in multiple
installations on a single host or even less create confusion between
different hosts in the same domain. I'd be willing to work on this if
one of the API authors could confirm that I am not on the wrong track.

Patrick, a last question, just to make something sure. Do you know for
sure that the reason for setting the cookies the way the API does
("generalizing" the domain and the path) is only for making sitemgr
possible or is there something else?

Michael