[Top][All Lists]
[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
- [Phpgroupware-users] new class.sessions_php4.inc.php breaks old logins, Patrick Oliver, 2002/09/14
- Re: [Phpgroupware-users] new class.sessions_php4.inc.php breaks old logins, Mark A Peters (Skeeter), 2002/09/14
- Re: [Phpgroupware-users] new class.sessions_php4.inc.php breaks old logins, Patrick J. Walsh, 2002/09/14
- Re: [Phpgroupware-users] new class.sessions_php4.inc.php breaks old logins,
Patrick Oliver <=
- Re: [Phpgroupware-users] new class.sessions_php4.inc.php breaks old logins, Patrick Oliver, 2002/09/15
- Re: [Phpgroupware-users] new class.sessions_php4.inc.php breaks old logins, Patrick J. Walsh (mr_e), 2002/09/15
- Re: [Phpgroupware-users] new class.sessions_php4.inc.php breaks old logins, Patrick Oliver, 2002/09/15
- Message not available
- Message not available
- Re: [Phpgroupware-users] new class.sessions_php4.inc.php breaks old logins, Patrick J. Walsh, 2002/09/15
- Re: [Phpgroupware-users] new class.sessions_php4.inc.php breaks old logins, Patrick J. Walsh, 2002/09/15