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 J. Walsh
Subject: Re: [Phpgroupware-users] new class.sessions_php4.inc.php breaks old logins
Date: Sun, 15 Sep 2002 12:57:35 -0700

> Seems to work just fine... But I also notice something which may or may not
> be a problem: the cookies are getting set within the domain of
> 'domain.com,' not 'host.domain.com.' By contrast, the PHPSESSID cookie is
> set within the 'host.domain.com' domain.

        Are you sure that the domain isn't being set as ".domain.com"?  That 
would be 
cover host.domain.com, host2.domain.com, etc.

> Login. Resulting cookies (last_loginid, last_domain, Domain, kp3,
> sessionid) are placed in domain.com, path /. PHPSESSID is placed in
> host.domain.com, path /.

        Hmmmm... sounds like maybe if you have phpgroupware running on 
different 
hosts and you want someone to be able to keep their session between them then 
you need to use db sessions instead of php4 sessions.

> Logout. New cookies appear in host.domain.com, path /phpgroupware: Domain,
> kp3, and sessionid. However, they have blank values. The old cookies are
> still there with their previous values. (All but the last_* cookies are
> non-persistent.)

        Doh!  Sounds like you found a bug.  To delete a cookie you have to give 
the 
exact same parameters as when you created it.  Apparently there's a delete 
cookie function somewhere that's doing something different than the setcookie 
function.

        Thanks for the update.  I'll put the fix in place and look into the 
cookie 
deletion bug.

mr_e

> On Sunday 15 September 2002 12:13 pm, you wrote:
> > Patrick,
> >
> >     I wonder if you would mind doing me a favor?  Assuming you are using
> > php4 sessions (there's a setting in header.inc.php), find the
> > phpgw_set_domain function in the class.sessions_php4.inc.php file and try
> > changing this line:
> >
> > $dom = $GLOBALS['HTTP_HOST'];
> >
> > to:
> >
> > $dom = $GLOBALS['HTTP_SERVER_VARS']['HTTP_HOST'];
> >
> > and then, for testing purposes, remove the if statement that I had you
> > had to fix your problem so that only the line:
> >
> > $this->dom = '.'.$parts ...
> >
> > is executed.
> >
> >     Then see if you can login.
> >
> >     Or, if you're able to view your cookies, for example using the Cookie
> > Manager of Mozilla, then you don't have to remove the if statement but
> > can instead inspect your cookies to see if the new ones have the domain
> > set.  I suspect that this simple change will cause $dom to have a value
> > and your domain to be set, but I'd appreciate it if you'd confirm that.
> >
> > Thanks,
> >
> > Patrick (aka mr_e)
> >
> >
> > --On Sunday, September 15, 2002 11:49 AM -0700,
> >
> > --Patrick Oliver <address@hidden> wrote:
> > > 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]