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: Sun, 15 Sep 2002 11:49:43 -0700
User-agent: KMail/1.4.3

On Sunday 15 September 2002 01:22 am, Patrick J. Walsh (mr_e) wrote:
> Patrick,
>
>       Interesting.  Are you using Apache?  Under Linux?  If the answer to both
> of those questions is yes, then the only thing left to suspect is the ssl.
> Let me know because I would like to investigate this a little bit further.
> Apparently $GLOBALS['HTTP_HOST'] is not returning a value on your setup and
> I am curious as to why that is.

I'm running apache 1.3.26 with mod_ssl 2.8.10 on FreeBSD 4.6.2-RELEASE. PHP 
version 4.2.2.

I just did a quick phpinfo() check (using https access) and the 
$_SERVER["HTTP_HOST"] is indeed defined correctly as 'host.domain.com'. I 
don't use a ServerName setting in apache's httpd.conf, but UseCanonicalName 
is on. (According to my understanding of the documentation in the file, this 
setting should be irrelevant since I don't have a ServerName. In any case, 
the URLs never seem to get munged by the server.)

I've forgotten the exact deal on PHP 4.2.2, but can you access 
$_SERVER["HTTP_HOST"] with $GLOBALS["HTTP_HOST"] as you say?

Let me know if I can provide more information.

Patrick



>
> ..mr_e
>
>
> --On Saturday, September 14, 2002 9:44 PM -0700,
>
> --Patrick Oliver <address@hidden> wrote:
> > 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 mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-users





reply via email to

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