RE: [Phplib-users] killing sessions when closing browser

[Daniel B. <bo...@io...>]

I've gone through all the steps below and I've tracked down the problem =
to IE 6
All other browsers are behaving as they should.

cookies are being set as
lifetime =3D 0
path =3D /
domain =3D=20
secure =3D=20

Has anyone else run into this problem.

thanks



-----Original Message-----
From: Nathaniel Price [mailto:np...@te...]
Sent: Tuesday, July 15, 2003 12:04 PM
To: Daniel Bondurant; php...@li...
Subject: Re: [Phplib-users] killing sessions when closing browser



----- Original Message -----=20
From: "Daniel Bondurant" <bo...@io...>
To: <Php...@li...>
Sent: Monday, July 14, 2003 11:45 AM
Subject: [Phplib-users] killing sessions when closing browser


> After I upgraded to phplib 7.4-pre2, and can't seem to get sessions to =
be
destroyed when a browser is closed and then reopened.  Before the user =
would
have to log in again, now they are still logged in.
>
> How do I force the login when the browser is closed and then =
re-opened.
>
> I have Session set to:
> $allowcache =3D no
> $lifetime =3D 0  (for session cookies)

Well, you can't really force an explicit logout when the browser is =
closed
(unless you resort to some somewhat unreliable Javascript trickery, as
someone else already mentioned). However, using session cookies (as =
opposed
to persistent cookies) for the PHPlib session ID should, in effect, =
cause a
'logout' of sorts (in reality what happens is that the old, =
authenticated
session is abandoned, and a new one is created when the browser opens).

Your settings appear to be correct for the desired behavior, although =
you
might want to make sure that $mode is set to 'cookie' as well. You might
also want to take a look at the cookie that PHPlib sets to make sure =
that it
is a 'session' cookie instead of a persistent cookie. If it's setting a
persistant cookie, take a look through your subclass(es) of Session and =
make
sure that the instance variables are being set correctly (i.e. if you =
set
these settings in session.inc's Session, but use a different setting in =
the
subclass of Session in local.inc, the local.inc subclass would override =
the
settings in the session.inc class). Use the subclass in local.inc to set
these settings whenever possible.

If that's not the problem, make sure there aren't any problems in your
'auth' scheme. Pay special attention to your
auth_validatelogin()/auth_doregister() and auth_preauth() methods in =
your
Auth subclass to make sure that there isn't something there that is =
logging
in your users some other way, which doesn't rely on PHPlib's sessions.

Also, you'll want to make sure that if your app is using 'get' as the
default mode, or for some reason $fallback_mode is being used instead of
$mode, that the browser isn't automatically appending the session id to =
the
URL after the browser is closed. Normally, this shouldn't happen, =
however it
is possible that bookmarks/favorites with the session id in the url or a
'start browser on the last page I visited' setting could cause an old
session to be used. Unfortunately there's not much you can do about this
kind of problem (since you can't control whether a client bookmarks a =
page
or uses different settings), although to help alleviate it, you'll want =
to
set $gc_time to a relatively low value. This will garbage-collect old
sessions automatically, and make it so that an old session cannot be
ressurected if it is older than $gc_time minutes old. (at least that's =
the
way I understand it). If you're using 'cookie' mode (and it is working =
as it
should) this paragraph shouldn't apply to you. Check the docs here:
http://www.sanisoft.com/phplib/manual/session.php

Although it is not set up in the default install of PHPlib, if you have =
a
customized auto_init file for Session, you might want to look through =
that
to make sure that it doesn't reset the cookies or anything. As I said, =
if
you haven't mucked around with it, it shouldn't be a problem. For more =
info
see: http://www.sanisoft.com/phplib/manual/using_autoinit.php

Also, poorly behaved web-proxies might cause the behavior you described. =
If
you use a web proxy, try disabling it (if you can) or talk to your =
system
administrator.

Hope this helps...

_________________________________
Nathaniel Price <np...@te...>
Webmaster