Frustrating Session problem.....

[David Powicki]

This is a funky one.  Hopefully I can explain it well enough for people
to understand what is going on....

OK, we have two versions of IMP running on different servers: 2.2.0
(running off a postgres DB) and 2.2.5-cvs (running off a mysql DB). Each
of the them has the recommended versions of PHP and PHPlib.  Both are
configured with session time-outs of 30 min (done by setting
$lifetime=30 in local.inc).  

Now here is the problem.

IE on the PC immediately times-out sessions if the PC's clock is off by
more than 30 minutes when connecting against the 2.2.5 server, but not
the 2.2.0 server.  

Netscape does not care what the PC time is for both versions of IMP.  No
matter what I set the time to it works fine.

I sniffed all combinations of traffic between the different browser
versions and imp versions.  Here's what I came up with:

Apparently the root of the problem lies in the fact that IE passes the
session identifier to the server via the URL when running against the
2.2.0 version, but not with 2.2.5 version.  The session identifier is
passed via a URL even though I have cookies enabled.  Using the same
version of IE against 2.2.5 the browser passes the session information
as a cookie value, and not via the url. When the clock is set correctly
this is not a problem because the session cookie is passed, but when the
clock is off, IE appears to time out the cookie internally and does not
pass it back to the server.   Netscape on the other hand passes the
cookie no matter what the session timeout is...

Perhaps this internal cookie processing is a feature in IE......

Anyhow, has anyone heard of a similar problem?


Thanks

David




--

David Powicki     Network Analyst/Postmaster     OIT Network Services
Voice: 413.545.1605  Fax: 413.545.3203    University of Massachusetts
email: dpowicki@nic.umass.edu             Amherst, MA 01003-4640


>From chuck@horde.org Date: Tue,  3 Apr 2001 11:28:45 -0400
Return-Path: <chuck@horde.org>
Mailing-List: contact imp-help@lists.horde.org; run by ezmlm
Delivered-To: mailing list imp@lists.horde.org
Received: (qmail 29345 invoked from network); 3 Apr 2001 15:29:55 -0000
Received: from 208-59-250-206.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO marina.horde.org) (208.59.250.206)
  by horde.org with SMTP; 3 Apr 2001 15:29:55 -0000
Received: by marina.horde.org (Postfix, from userid 33)
	id E0CBF3CA6; Tue,  3 Apr 2001 11:28:45 -0400 (EDT)
Received: from 206.243.191.252 ( [206.243.191.252])
	as user chuck@localhost by marina.horde.org with HTTP;
	Tue,  3 Apr 2001 11:28:45 -0400
Message-ID: <986311725.3ac9ec2da44da@marina.horde.org>
Date: Tue,  3 Apr 2001 11:28:45 -0400
From: Chuck Hagenbuch <chuck@horde.org>
To: imp@lists.horde.org
References: <20010403152755.A5927@turp.sytes.net> <20010403094821.E15328@alcor.concordia.ca> <20010403155755.A6069@turp.sytes.net> <20010403100828.G15328@alcor.concordia.ca> <3AC9F81A.F2B05B99@oit.umass.edu>
In-Reply-To: <3AC9F81A.F2B05B99@oit.umass.edu>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Subject: Re: [imp] Frustrating Session problem.....

Quoting David Powicki <dpowicki@oit.umass.edu>:

> Apparently the root of the problem lies in the fact that IE passes the
> session identifier to the server via the URL when running against the
> 2.2.0 version, but not with 2.2.5 version.  The session identifier is
> passed via a URL even though I have cookies enabled.  Using the same
> version of IE against 2.2.5 the browser passes the session information
> as a cookie value, and not via the url. When the clock is set correctly
> this is not a problem because the session cookie is passed, but when the
> clock is off, IE appears to time out the cookie internally and does not
> pass it back to the server.   Netscape on the other hand passes the
> cookie no matter what the session timeout is...

Basically, if you want to set a cookie with a set lifetime (instead of a 
session cookie, which lasts until the browser is closed and would be set by 
using lifetime=0), you're (in some, though obviously not all, cases) at the 
mercy of the client's clock being correct.

-chuck

--
Charles Hagenbuch, <chuck@horde.org>
Number of U.S. nuclear bombs lost in accidents and never recovered: 11