Sessions and closing the browser

Question for the group

The authentication system for the site Im working on seems to function
properly and all is good. A session keeps track of everything and a
cookie is used to accept or deny access... sounds as it should be I hope.
Then when all is done logging out destroys everything and the pages are
no longer accessable. Good so far.

But two things come to mind: one is preventing multiple logins of the
user/password. The solution from what Ive read seems to be using another
variable to check whether or not the user is already logged in (a simple
yes or no). Simple enough. I imagine logging out normally and deleting
all values removes this and then the cookie is deleted. But, what if the
browser is simply closed? If I understand how everything works the cookie
will still be there for a set period until its removed automatically.
What if the user logs in, closes the browser, and tries to log in again?
Is the value saying the login already exists still there? Or am I
thinking I need a solution to a problem that is already transparently
handled?

thx

(note: I sent an email about this earlier today, but I dont see it so Im
sending it again)

re: Sessions and closing the browser

In article <Xns956EA0914D80densnews123@216.168.3.44>, Theo wrote:[color=blue]
> Question for the group
>
> The authentication system for the site Im working on seems to function
> properly and all is good. A session keeps track of everything and a
> cookie is used to accept or deny access... sounds as it should be I hope.
> Then when all is done logging out destroys everything and the pages are
> no longer accessable. Good so far.
>
> But two things come to mind: one is preventing multiple logins of the
> user/password. The solution from what Ive read seems to be using another
> variable to check whether or not the user is already logged in (a simple
> yes or no). Simple enough. I imagine logging out normally and deleting
> all values removes this and then the cookie is deleted. But, what if the
> browser is simply closed? If I understand how everything works the cookie
> will still be there for a set period until its removed automatically.
> What if the user logs in, closes the browser, and tries to log in again?
> Is the value saying the login already exists still there? Or am I
> thinking I need a solution to a problem that is already transparently
> handled?[/color]

Instead of yes/no store the timestamp. And save that timestamp in the
session.

Everytime a user requests as page, compare the session timestamp with
the timestamp in the database.

If a new login has been done, the timestamp will be different.



--
Tim Van Wassenhove <http://www.timvw.info>

re: Sessions and closing the browser

On Fri, 24 Sep 2004 22:45:53 -0000, Theo <invalid@noemail.com> wrote:
[color=blue]
>Question for the group
>
>The authentication system for the site Im working on seems to function
>properly and all is good. A session keeps track of everything and a
>cookie is used to accept or deny access... sounds as it should be I hope.
>Then when all is done logging out destroys everything and the pages are
>no longer accessable. Good so far.
>
>But two things come to mind: one is preventing multiple logins of the
>user/password. The solution from what Ive read seems to be using another
>variable to check whether or not the user is already logged in (a simple
>yes or no). Simple enough. I imagine logging out normally and deleting
>all values removes this and then the cookie is deleted. But, what if the
>browser is simply closed? If I understand how everything works the cookie
>will still be there for a set period until its removed automatically.
>What if the user logs in, closes the browser, and tries to log in again?
>Is the value saying the login already exists still there? Or am I
>thinking I need a solution to a problem that is already transparently
>handled?
>
>thx
>
>(note: I sent an email about this earlier today, but I dont see it so Im
>sending it again)[/color]


Right.. so are you using _SESSIONs or _COOKIEs? (or both?)

By default, both have "the same" lifespan.. for the duration of the
session. When the user closes the browser, the _SESSION or _COOKIE data
is removed (presuming you're not using cookies and setting a specified
expiration date) thus I believe you're looking for an answer to an
irrelevant question as when the user closes the browser, _all_ session
data will be destroyed, including the 'i_am_logged_in' value.. whatever
you use to distinguish =)


HTH.



Regards,

Ian

--
Ian.H
digiServ Network
London, UK
http://digiserv.net/

re: Sessions and closing the browser

>The authentication system for the site Im working on seems to function[color=blue]
>properly and all is good. A session keeps track of everything and a
>cookie is used to accept or deny access... sounds as it should be I hope.
>Then when all is done logging out destroys everything and the pages are
>no longer accessable. Good so far.
>
>But two things come to mind: one is preventing multiple logins of the
>user/password.[/color]

Why? What problem are you trying to solve here?

If the intent is to prevent the sharing of pay site logins, you're
trading one problem for another (denial of access by the legitimate
user). Of course, the site operator might like this problem, as
it costs less in bandwidth. But he might lose customers and his
site might get a bad reputation.

If the intent is some kind of security for abandoned sessions or
computers left unattended, put a timestamp in the session. Update
the timestamp to the current time on each successful page load (this
part comes after the logged-in check). On each page, the logged-in
check should include checking that the timestamp is not "too old"
(whatever value you decide for that). If it is (or the login is
otherwise invalid, say, the membership expired), destroy the session
and redirect to the login page. This should take care of "abandoned
sessions": any sessions older than the timeout aren't any good any
more and they get destroyed if anyone attempts to use them. You
should also have an occasional cleanup process that deletes old
sessions which nobody attempted to use after they were abandoned
(mostly to reclaim disk space). Oh, yes, DON'T count on browsers
to delete a cookie at the appropriate time. Some desktops have
clocks that, well, suck, and may be years off. Also, sniffed cookies
may be resurrected on another computer somewhere, with a tricked-up
browser that doesn't behave like you expect.

Your definition of "too old" should take into account what users
are doing with the pages: if it takes an average user 15 minutes
to fill in ONE form or compose message text, chances are a timeout
of 20 minutes is too short.

If the intent is some kind of assumption that if there are duplicate
logins, one MUST be an unauthorized cracker or will screw up your
application, well, that assumption is often false. It's not that
uncommon for me to have several browsers running on several computers
viewing the same site all on the same monitor. Your application
should distinguish carefully between per-USER data and per-SESSION
data (for example, each session has its own shopping cart, but the
paid-until date is shared by all sessions for the same user, and
the download limit is probably per-user, not per-session).

Incidentally, I think for many applications, if you must prevent
duplicate logins, on detection of a duplicate, allow the current
login and log out ALL THE OTHERS using the same username. (I'm not
real sure how to do this in a bulletproof way, but if you use session
handlers to put the session data in a database rather than the
default temporary files, finding other sessions with the same
username becomes easier. They'd go back to the login page on the
next attempt to load a page.) This prevents legitimate users from
having a number of problems including having their system crash/reboot
and then not being able to get back in until after an annoyingly
long timeout.
[color=blue]
>The solution from what Ive read seems to be using another
>variable to check whether or not the user is already logged in (a simple
>yes or no). Simple enough. I imagine logging out normally and deleting
>all values removes this and then the cookie is deleted. But, what if the
>browser is simply closed?[/color]

If there is another session with the same username AND the timestamp
is not stale, you have a duplicate login. Act accordingly. It
MIGHT be caused by a recently-closed browser. The situation will
correct itself after the timeout period.

If there is another session with the same username and the timestamp
is stale, this might be a case of just closing the browser. You ought
to ignore records with stale timestamps (as though they don't exist),
as they can't be used any more.
[color=blue]
>If I understand how everything works the cookie
>will still be there for a set period until its removed automatically.
>What if the user logs in, closes the browser, and tries to log in again?
>Is the value saying the login already exists still there? Or am I[/color]

Most likely, YES, and the user will be locked out. If you are
using timestamps, the lockout will only be for the timeout period.
[color=blue]
>thinking I need a solution to a problem that is already transparently
>handled?[/color]

Gordon L. Burditt

re: Sessions and closing the browser

Ian.H <ian@WINDOZEdigiserv.net> wrote in
news:v7i9l0pgs8m4vgq5ekg60b83hcg86bb86g@4ax.com:
[color=blue]
> Right.. so are you using _SESSIONs or _COOKIEs? (or both?)
>
> By default, both have "the same" lifespan.. for the duration of the
> session. When the user closes the browser, the _SESSION or _COOKIE
> data is removed (presuming you're not using cookies and setting a
> specified expiration date) thus I believe you're looking for an answer
> to an irrelevant question as when the user closes the browser, _all_
> session data will be destroyed, including the 'i_am_logged_in' value..
> whatever you use to distinguish =)
>
> HTH.
>
> Regards,
>
> Ian
>[/color]

Session cookies (as opposed to cookies on the users computer). Yes the
cookie does have an expiration date, so it will no longer work if the
computer is left unattended for a set time, say an hour. Several of the
authentication examples I read sets the time... then sets the time limit
to a negative amount (or before the current time) on logout so it will be
deleted when the session is ended. If I read the other post correctly,
perhaps the thing to do is store the last time any protected page was
accessed, get the time of next access, and if the difference is more than
1 hour, delete the current session and redirect to the login page?

re: Sessions and closing the browser

Theo <invalid@noemail.com> wrote in message news:<Xns956EA0914D80densnews123@216.168.3.44>...[color=blue]
> Question for the group
>
> The authentication system for the site Im working on seems to function
> properly and all is good. A session keeps track of everything and a
> cookie is used to accept or deny access... sounds as it should be I hope.
> Then when all is done logging out destroys everything and the pages are
> no longer accessable. Good so far.
>
> But two things come to mind: one is preventing multiple logins of the
> user/password. The solution from what Ive read seems to be using another
> variable to check whether or not the user is already logged in (a simple
> yes or no). Simple enough. I imagine logging out normally and deleting
> all values removes this and then the cookie is deleted. But, what if the
> browser is simply closed? If I understand how everything works the cookie
> will still be there for a set period until its removed automatically.
> What if the user logs in, closes the browser, and tries to log in again?
> Is the value saying the login already exists still there? Or am I
> thinking I need a solution to a problem that is already transparently
> handled?[/color]

1. <http://martin.f2o.org/php/login>
2. Session _may_ also use cookies (just to store the session id)
3. If you want to avoid multiple logins, just store the session id in
user table (when he logins) and see (on every pages) if the user's
current session id is the one which is stored in DB when logins.
Storing IP may also sometimes work, but if the user is behind proxy,
it will create problem.
4. No need to check timestamp as session will expire after the
specified time in INI settings.

--
| Just another PHP saint |
Email: rrjanbiah-at-Y!com

re: Sessions and closing the browser

In article <Xns956ED2E299642densnews123@216.168.3.44>, Theo wrote:[color=blue]
> If I read the other post correctly,
> perhaps the thing to do is store the last time any protected page was
> accessed, get the time of next access, and if the difference is more than
> 1 hour, delete the current session and redirect to the login page?[/color]

If you're referring to mine, you've misunderstood ;)


user logs in -> store current time in session and in database.
user requests page -> compare session and database time.


If the user logs in a second time, the time in the database will change.
So the first session time != database time.


This way:

They can always log in. (Don't have to wait for expiration time)
Only the last session will be valid.

--
Tim Van Wassenhove <http://www.timvw.info>

re: Sessions and closing the browser

Tim Van Wassenhove <euki@pi.be> wrote in
news:2rkh82F1bhn1qU1@uni-berlin.de:
[color=blue]
> In article <Xns956ED2E299642densnews123@216.168.3.44>, Theo wrote:[color=green]
>> If I read the other post correctly,
>> perhaps the thing to do is store the last time any protected page was
>> accessed, get the time of next access, and if the difference is more
>> than 1 hour, delete the current session and redirect to the login
>> page?[/color]
>
> If you're referring to mine, you've misunderstood ;)
>
>
> user logs in -> store current time in session and in database.
> user requests page -> compare session and database time.
>
>
> If the user logs in a second time, the time in the database will
> change. So the first session time != database time.
>
>
> This way:
>
> They can always log in. (Don't have to wait for expiration time)
> Only the last session will be valid.
>[/color]

wouldnt be the first time I dont get something right off the bat. But it
sounds like in the above that login #2 would override #1, whether or not
#1 is still active.

re: Sessions and closing the browser

In article <Xns956FCCE134Cdensnews123@216.168.3.44>, Theo wrote:[color=blue]
> Tim Van Wassenhove <euki@pi.be> wrote in
> news:2rkh82F1bhn1qU1@uni-berlin.de:
>[color=green]
>> In article <Xns956ED2E299642densnews123@216.168.3.44>, Theo wrote:[color=darkred]
>>> If I read the other post correctly,
>>> perhaps the thing to do is store the last time any protected page was
>>> accessed, get the time of next access, and if the difference is more
>>> than 1 hour, delete the current session and redirect to the login
>>> page?[/color]
>>
>> If you're referring to mine, you've misunderstood ;)
>>
>>
>> user logs in -> store current time in session and in database.
>> user requests page -> compare session and database time.
>>
>>
>> If the user logs in a second time, the time in the database will
>> change. So the first session time != database time.
>>
>>
>> This way:
>>
>> They can always log in. (Don't have to wait for expiration time)
>> Only the last session will be valid.
>>[/color]
>
> wouldnt be the first time I dont get something right off the bat. But it
> sounds like in the above that login #2 would override #1, whether or not
> #1 is still active.[/color]

Yes, that is the concept of one login per account, no? :)

--
Tim Van Wassenhove <http://www.timvw.info>

re: Sessions and closing the browser

"Theo" <invalid@noemail.com> wrote in message
news:Xns956EA0914D80densnews123@216.168.3.44...[color=blue]
> Question for the group
>
> The authentication system for the site Im working on seems to function
> properly and all is good. A session keeps track of everything and a
> cookie is used to accept or deny access... sounds as it should be I hope.
> Then when all is done logging out destroys everything and the pages are
> no longer accessable. Good so far.
>
> But two things come to mind: one is preventing multiple logins of the
> user/password. The solution from what Ive read seems to be using another
> variable to check whether or not the user is already logged in (a simple
> yes or no). Simple enough. I imagine logging out normally and deleting
> all values removes this and then the cookie is deleted. But, what if the
> browser is simply closed?[/color]

If the browser is closed then nothing is sent to the web server to say so,
so any session data you have on the server will just hang around until
something happens. This can be one of the following:
(a) Another request appears which references that session_id.
(b) Expired session data is deleted by PHP.
[color=blue]
> If I understand how everything works the cookie
> will still be there for a set period until its removed automatically.[/color]

By default the cookie which stores the session name and session id is a
temporary cookie. This means that it resides in memory only for the duration
of that browser session. If the user closes his browser, opens it again and
access your site there will be no session cookie for that new browser
session, so PHP will create a new session.

OTOH if the user logs in then opens up a new browser window and logs in
again then both browser instances will share the same session cookie
therefore the same session data. Even if the second login were to generate a
new session id this would be written out to the session cookie and therefore
picked up by the first login.

--
Tony Marston

http://www.tonymarston.net


[color=blue]
> What if the user logs in, closes the browser, and tries to log in again?
> Is the value saying the login already exists still there? Or am I
> thinking I need a solution to a problem that is already transparently
> handled?
>
> thx
>
> (note: I sent an email about this earlier today, but I dont see it so Im
> sending it again)[/color]

re: Sessions and closing the browser

R. Rajesh Jeba Anbiah wrote:[color=blue]
> Theo <invalid@noemail.com> wrote in message
> news:<Xns956EA0914D80densnews123@216.168.3.44>...[color=green]
>> Question for the group[/color]
>
> Storing IP may also sometimes work, but if the user is behind proxy,
> it will create problem.[/color]

Will it, I think not necessarily. I agree one must not rule out multiple IP
logins per IP, but the combination username/pwd & IP can still be set to one
max, but different logins from one Ip isn't a reason in itself to close a
session or am I missing something ? (Hope not, I am gambling on this to
work!)

re: Sessions and closing the browser

Pjotr Wedersteers <x33159@westerterp.com> wrote:[color=blue]
> Will it, I think not necessarily. I agree one must not rule out multiple IP
> logins per IP, but the combination username/pwd & IP can still be set to one
> max[/color]

Loadbalancing proxies! I ipersonally would never do anything with
the users ipaddress.

--

Daniel Tryba

re: Sessions and closing the browser

Tim Van Wassenhove <euki@pi.be> wrote in
news:2rklb1F1bb9apU1@uni-berlin.de:
[color=blue][color=green]
>> wouldnt be the first time I dont get something right off the bat. But
>> it sounds like in the above that login #2 would override #1, whether
>> or not #1 is still active.[/color]
>
> Yes, that is the concept of one login per account, no? :)[/color]

What if #1 shouldnt be overridden because the person is actually using
it... and #2 is someone else using the same logon?

re: Sessions and closing the browser

In article <Xns956F676267575densnews123@216.168.3.44>, Theo wrote:[color=blue]
> Tim Van Wassenhove <euki@pi.be> wrote in
> news:2rklb1F1bb9apU1@uni-berlin.de:
>[color=green][color=darkred]
>>> wouldnt be the first time I dont get something right off the bat. But
>>> it sounds like in the above that login #2 would override #1, whether
>>> or not #1 is still active.[/color]
>>
>> Yes, that is the concept of one login per account, no? :)[/color]
>
> What if #1 shouldnt be overridden because the person is actually using
> it... and #2 is someone else using the same logon?[/color]

Then you should only verify if their credetials are correct.
And do nothing more.

--
Tim Van Wassenhove <http://www.timvw.info>

re: Sessions and closing the browser

Tim Van Wassenhove <euki@pi.be> wrote in
news:2rlnvfF1bhm5jU1@uni-berlin.de:
[color=blue]
> In article <Xns956F676267575densnews123@216.168.3.44>, Theo wrote:[color=green]
>> Tim Van Wassenhove <euki@pi.be> wrote in
>> news:2rklb1F1bb9apU1@uni-berlin.de:
>>[color=darkred]
>>>> wouldnt be the first time I dont get something right off the bat.
>>>> But it sounds like in the above that login #2 would override #1,
>>>> whether or not #1 is still active.
>>>
>>> Yes, that is the concept of one login per account, no? :)[/color]
>>
>> What if #1 shouldnt be overridden because the person is actually
>> using it... and #2 is someone else using the same logon?[/color]
>
> Then you should only verify if their credetials are correct.
> And do nothing more.
>[/color]

I know Im thinking worst case scenario. Really I dont expect this to
happen or and simply using a logon setting with a timestamp for old
logins will work good enough. I guess Im being paranoid ;o)

re: Sessions and closing the browser

"Tony Marston" <tony@NOSPAM.demon.co.uk> wrote in
news:cj3clh$e7$1$830fa79f@news.demon.co.uk:
[color=blue]
> OTOH if the user logs in then opens up a new browser window and logs
> in again then both browser instances will share the same session
> cookie therefore the same session data. Even if the second login were
> to generate a new session id this would be written out to the session
> cookie and therefore picked up by the first login.[/color]

I tested out some 'real' sites by logging in twice using different browsers
(IE and Firefox) at the same time, and both worked, allowing access to
everything. Did the same thing on my local one - there are two sessions, as
expected. I guess maybe multiple logins are not that big of a concern in
the grand scheme of things even for large sites.

Then again maybe they checked to see if the two logins were coming two
different IPs, and since they were not, didnt prevent anything.

re: Sessions and closing the browser

> 3. If you want to avoid multiple logins, just store the session id in[color=blue]
> user table (when he logins) and see (on every pages) if the user's
> current session id is the one which is stored in DB when logins.
> Storing IP may also sometimes work, but if the user is behind proxy,
> it will create problem.[/color]

Instead of that, I would destroy the previous session when the user login
in, using the session id stored in the database to locate the session file.
This way, when the user shutdowns the browser without logging out properly,
he wouldn't be prevented from logging in again.

Don't think there's any bulletproof way to stop people from sharing the same
session id. That's more a theoretical problem though.

re: Sessions and closing the browser

"Chung Leong" <chernyshevsky@hotmail.com> wrote in
news:zq2dnWJnPMXNpcvcRVn-rQ@comcast.com:
[color=blue][color=green]
>> 3. If you want to avoid multiple logins, just store the session id in
>> user table (when he logins) and see (on every pages) if the user's
>> current session id is the one which is stored in DB when logins.
>> Storing IP may also sometimes work, but if the user is behind proxy,
>> it will create problem.[/color]
>
> Instead of that, I would destroy the previous session when the user
> login in, using the session id stored in the database to locate the
> session file. This way, when the user shutdowns the browser without
> logging out properly, he wouldn't be prevented from logging in again.
>
> Don't think there's any bulletproof way to stop people from sharing
> the same session id. That's more a theoretical problem though.
>
>
>[/color]

True. I suppose it I wanted to be really security minded I could force
password renewal every 30 days. Either that or have a set of 10 semi-
personal questions, 1 of which must be answered in addition to the usual
uid/pwd. Now this is getting really too much. Its not like Im making
something for the DoD ;o)

re: Sessions and closing the browser

"Theo" <invalid@noemail.com> wrote in message
news:Xns956F8AD99F792densnews123@216.168.3.44...[color=blue]
> "Tony Marston" <tony@NOSPAM.demon.co.uk> wrote in
> news:cj3clh$e7$1$830fa79f@news.demon.co.uk:
>[color=green]
>> OTOH if the user logs in then opens up a new browser window and logs
>> in again then both browser instances will share the same session
>> cookie therefore the same session data. Even if the second login were
>> to generate a new session id this would be written out to the session
>> cookie and therefore picked up by the first login.[/color]
>
> I tested out some 'real' sites by logging in twice using different
> browsers
> (IE and Firefox) at the same time, and both worked, allowing access to
> everything.[/color]

The fact that they allowed multiple logins using the same username does not
mean that they are using separate session ids. If they share the same
session id then they are sharing the same session data, so what you do in
one window will be available in another.
[color=blue]
> Did the same thing on my local one - there are two sessions, as
> expected. I guess maybe multiple logins are not that big of a concern in
> the grand scheme of things even for large sites.
>
> Then again maybe they checked to see if the two logins were coming two
> different IPs, and since they were not, didnt prevent anything.[/color]

I know for a fact that if you open up multiple browser windows using IE they
will all share the same session cookie, therefore they will share the same
session name and, by association, the same session id.

Different browsers on the same PC may not share the same session cookie, in
which case they would not be sharing the same session id.

--
Tony Marston

http://www.tonymarston.net

re: Sessions and closing the browser

"Tony Marston" <tony@NOSPAM.demon.co.uk> wrote in
news:cj6407$so5$1$8302bc10@news.demon.co.uk:
[color=blue]
> I know for a fact that if you open up multiple browser windows using
> IE they will all share the same session cookie, therefore they will
> share the same session name and, by association, the same session id.
>
> Different browsers on the same PC may not share the same session
> cookie, in which case they would not be sharing the same session id.[/color]

Yes. This is what I did, as I figured another window in the same browser
wouldnt mean anything.

re: Sessions and closing the browser

Tony Marston <tony@NOSPAM.demon.co.uk> wrote:[color=blue]
> I know for a fact that if you open up multiple browser windows using IE they
> will all share the same session cookie, therefore they will share the same
> session name and, by association, the same session id.
>
> Different browsers on the same PC may not share the same session cookie, in
> which case they would not be sharing the same session id.[/color]

Depends on the way you use to open the other browser windows:
Session cookies are shared between the windows of a single IE process, so
if you open a new window using File > New > Window, the new window can
access the session cookie. But if you open a new "window" using Start > Run[color=blue]
> iexplore.exe, this IE is unable to access the session cookie of the other[/color]
window.
--
Simon Stienen <http://dangerouscat.net> <http://slashlife.de>
»What you do in this world is a matter of no consequence,
The question is, what can you make people believe that you have done.«
-- Sherlock Holmes in "A Study in Scarlet" by Sir Arthur Conan Doyle

re: Sessions and closing the browser

"Theo" <invalid@noemail.com> wrote in message
news:Xns957066065157Cdensnews123@216.168.3.44...[color=blue]
> "Tony Marston" <tony@NOSPAM.demon.co.uk> wrote in
> news:cj6407$so5$1$8302bc10@news.demon.co.uk:
>[color=green]
>> I know for a fact that if you open up multiple browser windows using
>> IE they will all share the same session cookie, therefore they will
>> share the same session name and, by association, the same session id.
>>
>> Different browsers on the same PC may not share the same session
>> cookie, in which case they would not be sharing the same session id.[/color]
>
> Yes. This is what I did, as I figured another window in the same browser
> wouldnt mean anything.[/color]

Most users do not have multiple browsers on their system, so this situation
is unlikely to occur.

Some users like to have multiple windows open at the same time, so this
situation is more likely to occur. Some users like to visit the same site in
different browser windows which can cause problems depending on the
behaviour of the browser, which is totally outside of your control.

If the different browser windows share the same session cookie then they
will all share the same session name and session id, which could cause a
problem.

If the browser creates a new window without reusing the existing session
cookie then the new window will have its own session name and session id.

With Internet Explorer for example a new window may or may not share the
same session cookie depending on how it was created:
- by File->New->Window it will share the same session cookie
- by Start->Run->Iexplore.exe it will use its own session cookie, therefore
a different session.

Other browsers, such as Firefox or Opera, may have different behaviour.

On the server side it is impossible to tell if the same session id is being
shared by multiple browser windows, so they will all be treated as if they
are the same session.

If you want to restrict each user to a single login then you have to bear
all this in mind.

--
Tony Marston

http://www.tonymarston.net

re: Sessions and closing the browser

"Tony Marston" <tony@NOSPAM.demon.co.uk> wrote in
news:cj8o1p$fb1$1$8300dec7@news.demon.co.uk:
[color=blue]
>
> "Theo" <invalid@noemail.com> wrote in message
> news:Xns957066065157Cdensnews123@216.168.3.44...[color=green]
>> "Tony Marston" <tony@NOSPAM.demon.co.uk> wrote in
>> news:cj6407$so5$1$8302bc10@news.demon.co.uk:
>>[color=darkred]
>>> I know for a fact that if you open up multiple browser windows using
>>> IE they will all share the same session cookie, therefore they will
>>> share the same session name and, by association, the same session
>>> id.
>>>
>>> Different browsers on the same PC may not share the same session
>>> cookie, in which case they would not be sharing the same session id.[/color]
>>
>> Yes. This is what I did, as I figured another window in the same
>> browser wouldnt mean anything.[/color]
>
> Most users do not have multiple browsers on their system, so this
> situation is unlikely to occur.
>
> Some users like to have multiple windows open at the same time, so
> this situation is more likely to occur. Some users like to visit the
> same site in different browser windows which can cause problems
> depending on the behaviour of the browser, which is totally outside of
> your control.
>
> If the different browser windows share the same session cookie then
> they will all share the same session name and session id, which could
> cause a problem.
>
> If the browser creates a new window without reusing the existing
> session cookie then the new window will have its own session name and
> session id.
>
> With Internet Explorer for example a new window may or may not share
> the same session cookie depending on how it was created:
> - by File->New->Window it will share the same session cookie
> - by Start->Run->Iexplore.exe it will use its own session cookie,
> therefore a different session.
>
> Other browsers, such as Firefox or Opera, may have different
> behaviour.
>
> On the server side it is impossible to tell if the same session id is
> being shared by multiple browser windows, so they will all be treated
> as if they are the same session.
>
> If you want to restrict each user to a single login then you have to
> bear all this in mind.
>[/color]

Thank You

I think the best way to know is to do alot of trial and error. I am just
about to that stage.