phpgroupware-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Patrick Oliver
Subject: Re: [Phpgroupware-users] new class.sessions_php4.inc.php breaks old logins
Date: Sat, 14 Sep 2002 21:44:25 -0700
User-agent: KMail/1.4.3

Hello Patrick,

Works like a charm, though I don't know why: your reasoning about using a 
non-dot domain name doesn't seem to apply to my setup.

I am using cookie based session handling with Opera as a browser, and using 
the non-working code, I can see the PHPSESSID cookie get set. My domain name 
is of the form https://server.domain.com/phpgw/. I am not using virtual 
hosts.

But again, I don't see how exactly your fix happens to make it work in my 
case, but I am not at all familiar with the code, so that isn't too 
surprising. :-)

Thanks for the quick action and response!

Patrick


On Saturday 14 September 2002 01:34 pm, Patrick J. Walsh (mr_e) wrote:
> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]