Re: [Phpgroupware-users] new class.sessions_php4.inc.php breaks old logins

[Patrick J. Walsh (mr_e)]

	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