[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: |
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
- [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, 2002/09/15
- 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 <=
- 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