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

[Patrick J. Walsh]

>       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.

        I've found a simple fix for this that is pretty elegant.  Will check it 
in to 
CVS, 0_9_14 branch, shortly.

>       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.

        Yup... needed to change the Setcookie lines in logout.php.  I'll check 
this 
into CVS branch 0_9_14 shortly as well.

..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
>
> _______________________________________________
> Phpgroupware-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-users