So here's the deal, multiple cookies are being sent and they look like
this:
Set-Cookie: last_domain=default; expires=Sat, 28-Sep-02 20:00:14 GMT;
path=/; domain=..servername\r\n
whereas the PHPSESSID looks exactly the same except doesn't have a
domain= portion.
In researching this, it turns out that the domain parameter must have
two dots to be valid. For example, 'servername.domain.com' is valid
because it has two dots. '.domain.com' is also valid and works for all
hosts in the domain.com domain. '..servername' is an invalid domain and
so the cookie is discarded. '.servername' and '.servername.local' are
also invalid because there are not two dots and the domain won't
resolve, respectively.
I've come up with the only fix that I can find. If Patrick Oliver would
kindly test it on his system I will (or skeeter will) update the sessions
classes.
In class.sessions_php4.inc.php and also class.sessions_db.inc.php there
is a phpgw_set_domain() function. [Note: now that we're no longer
supporting php3 we should really put common functions like this into a
parent class and make these two classes extend the parent.] Replace the
line:
$this->dom = '.'.$parts[count($parts)-2].'.'.$parts[count($parts)-1];
with:
if (count(parts)<2)
{
$this->dom = '';
}
else
{
$this->dom =
'.'.$parts[count($parts)-2].'.'.$parts[count($parts)-1];
}
this is around line 282 in class.sessions_php4.inc.php.
..mr_e
--On Saturday, September 14, 2002 12:34 PM -0700,
--"address@hidden" <address@hidden> wrote:
> I meant to point out that if I use the http://servername.domain.com/
> url everything works smoothly.
>
> ..mr_e
>
>
> --On Saturday, September 14, 2002 12:32 PM -0700,
>
> --"address@hidden" <address@hidden> wrote:
>> I've been able to reproduce this problem on my setup and I think I've
>> identified the problem (though not yet the solution). Perhaps Patrick
>> Oliver can confirm that his setup is similar.
>>
>> On my local network I can refer to the development server as
>> http://servername/, http://192.168.1.15/ (ip), or
>> http://servername.domain.com/. Obviously I'm making up values here,
>> but you get the idea. I typically use the http://servername/ url.
>> This is where things get messed up. Using mozilla as the client,
>> the cookie is never stored. This is essentially true for both 'db'
>> sessions and 'php4' sessions, although under php4 the builtin
>> PHPSESSID cookie is passed. The phpGroupWare cookies like
>> lastloginid and what not are not being passed or not being stored.
>>
>> I'm going to use a sniffer to see if I can figure out how PHP is
>> sending the cookie and what phpGW is doing differently. I'll post my
>> findings.
>>
>> ..mr_e
>>
>> On Saturday 14 September 2002 09:58 am, Mark A Peters (Skeeter) wrote:
>>> I have a couple of questions:
>>>
>>> 1) Are you using cookie based or URL based parameter passing?
>>>
>>> 2) Are you using a virtual host?
>>>
>>> I made, what I thought was a minor fix to the session class. The
>>> intent there was to allow better handling for use with the sitemgr
>>> app. I could've not taken into account a few assertions.
>>>
>>> Thanks,
>>> Mark A Peters (Skeeter)
>>>
>>> On Sat, 14 Sep 2002, Patrick Oliver wrote:
>>> > Hello,
>>> >
>>> > I've just upgraded via CVS to the latest 0.9.14 branch files, and
>>> > my old accounts no longer permit login.
>>> >
>>> > Reverting a single file to its prior version seems to do the trick,
>>> > so I suspect a change in that file was not backwards compatible for
>>> > my configuration.
>>> >
>>> > The file phpgwapi/inc/class.sessions_php4.inc.php version 1.6.2.3
>>> > (2002/09/12) does not "work." Installing my prior version of
>>> > 1.6.2.1 (2002/01/16) works (keeping all other files current).
>>> >
>>> > When I say it doesn't "work," I mean that attempting to log in via
>>> > a user or admin account returns to the login screen with no
>>> > message. Using the old file permits login to succeed.
>>> >
>>> > > From looking at the code, the big difference seems to be domain
>>> > > handling. In
>>> >
>>> > my installation, I don't use domains (as far as I know). Could it
>>> > be that an 'empty' domain isn't being handled properly?
>>> >
>>> > Let me know if there is any more information I can provide.
>>> >
>>> > Patrick
>>> >
>>> >
>>> > _______________________________________________
>>> > Phpgroupware-users mailing list
>>> > address@hidden
>>> > http://mail.gnu.org/mailman/listinfo/phpgroupware-users
>>>
>>> _______________________________________________
>>> Phpgroupware-users mailing list
>>> address@hidden
>>> http://mail.gnu.org/mailman/listinfo/phpgroupware-users
>>
>> _______________________________________________
>> Phpgroupware-users mailing list
>> address@hidden
>> http://mail.gnu.org/mailman/listinfo/phpgroupware-users
>
> _______________________________________________
> Phpgroupware-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-users
_______________________________________________
Phpgroupware-users mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/phpgroupware-users