Is Session Always Cleared?

[Jonathan Wood]

Greetings,

I was wondering if anyone here has a good understaning of the Session
object. I know there are options like the Session.Abandon method and the
regenerateExpiredSessionId setting, although I do not understand what they
do.

Can anyone tell me if it's possible for a recycled session to still contain
the old data? I had a couple of reports that where users said they logged on
and saw another user's data. On this site, there were a couple of cases
where I used the Session object to track information about the current user.

Thanks for any tips or links.

Jonathan

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Jonathan Wood wrote:

Greetings,

I was wondering if anyone here has a good understaning of the Session
object. I know there are options like the Session.Abandon method and the
regenerateExpiredSessionId setting, although I do not understand what
they do.

Can anyone tell me if it's possible for a recycled session to still
contain the old data? I had a couple of reports that where users said
they logged on and saw another user's data. On this site, there were a
couple of cases where I used the Session object to track information
about the current user.

Thanks for any tips or links.

Jonathan

The session id is stored in a cookie in the browser, and is matched
against the existing Session objects on the server.

If a Session object has timed out, it's gone forever. If an expired
session id is reused, a new empty Session object is created for it.

A session id could possible be spoofed, but that is hardly what your
users are doing, so the Session objects are most likely not the reason
why some user could see some other users data.

Are you using any static variables in your application?

--
Göran Andersson
_____
http://www.guffa.com

[Jonathan Wood]

"Göran Andersson" <gu***@guffa.comwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...

The session id is stored in a cookie in the browser, and is matched
against the existing Session objects on the server.

If a Session object has timed out, it's gone forever. If an expired
session id is reused, a new empty Session object is created for it.

A session id could possible be spoofed, but that is hardly what your users
are doing, so the Session objects are most likely not the reason why some
user could see some other users data.

Yeah, no one is trying to hack the site. So, as far as you are concerned,
one session would never see the Session data used by another user?

Are you using any static variables in your application?

No, I store any persisting data in the Session object or the database. It's
the first big site I created (although I've been programming for many, many
years). I'm now prepared to review my code in detail but, to be honest, I
really have no idea what this could be.

Note that, normally, the site works exactly as expected.

Thanks.

Jonathan

[Cowboy \(Gregory A. Beamer\)]

Your problem is not session. It is more likely you have a cache issue, a
singleton, static variables or the users are using the same computer.
Perhaps you have something stored in application, or you have tried some
form of global object. The session, used as a place to hang session data, is
not a problem.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://feeds.feedburner.com/GregoryBeamer#

or just read it:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************
"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:Ol**************@TK2MSFTNGP02.phx.gbl...

Greetings,

I was wondering if anyone here has a good understaning of the Session
object. I know there are options like the Session.Abandon method and the
regenerateExpiredSessionId setting, although I do not understand what they
do.

Can anyone tell me if it's possible for a recycled session to still
contain the old data? I had a couple of reports that where users said they
logged on and saw another user's data. On this site, there were a couple
of cases where I used the Session object to track information about the
current user.

Thanks for any tips or links.

Jonathan

[Jonathan Wood]

Thanks for the additional vote of confidence on Session.

There is a slight possibility that at least one of the users did log on as
other users. I will quiz them on if they might have logged on as the users
whose data they saw when they logged on as themselves.

I don't know that's the issue but I'll explore it. Is there as straight
forward way to allow multiple users to log on from the same computer?

Jonathan

"Cowboy (Gregory A. Beamer)" <No************@comcast.netNoSpamMwrote in
message news:%2****************@TK2MSFTNGP05.phx.gbl...

Your problem is not session. It is more likely you have a cache issue, a
singleton, static variables or the users are using the same computer.
Perhaps you have something stored in application, or you have tried some
form of global object. The session, used as a place to hang session data,
is not a problem.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://feeds.feedburner.com/GregoryBeamer#

or just read it:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************
"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:Ol**************@TK2MSFTNGP02.phx.gbl...

>Greetings,

I was wondering if anyone here has a good understaning of the Session
object. I know there are options like the Session.Abandon method and the
regenerateExpiredSessionId setting, although I do not understand what
they do.

Can anyone tell me if it's possible for a recycled session to still
contain the old data? I had a couple of reports that where users said
they logged on and saw another user's data. On this site, there were a
couple of cases where I used the Session object to track information
about the current user.

Thanks for any tips or links.

Jonathan

[Hans Kesting]

Jonathan Wood explained :

Thanks for the additional vote of confidence on Session.

There is a slight possibility that at least one of the users did log on as
other users. I will quiz them on if they might have logged on as the users
whose data they saw when they logged on as themselves.

I don't know that's the issue but I'll explore it. Is there as straight
forward way to allow multiple users to log on from the same computer?

Jonathan

What exactly do you mean by "multiple users logging in from the same
computer"?

If there is just one user at a time then there shouldn't be a problem.
If the first user closes his browser after he is finished, the session
cookie is forgotten. A new browser instance will use a new session.
When the first user logs out, you can destroy the session server side
(Session.Abandon).

However, two users at *the same time* from the same computer could lead
to problems. The various browser windows could use the same cookie set.
So when a second user opens a new window, he could be automatically
using the session of the first user.

I think that firefox uses the same cookieset for all it's windows. For
IE it depends on how the new window is started.

Hans Kesting

[Jonathan Wood]

Hans,

What exactly do you mean by "multiple users logging in from the same
computer"?

I'm sorry. It's hard to know how to better state it than that. Unless you
clarify which part is unclear.

If there is just one user at a time then there shouldn't be a problem.
If the first user closes his browser after he is finished, the session
cookie is forgotten. A new browser instance will use a new session.
When the first user logs out, you can destroy the session server side
(Session.Abandon).

Well, I don't know if it's a given that the browser was closed in between.
But even if it was, the cookie could remain after the browser is closed.
However, what if any data remains from that cookie is something I don't
know.

However, two users at *the same time* from the same computer could lead to
problems. The various browser windows could use the same cookie set. So
when a second user opens a new window, he could be automatically using the
session of the first user.

No, I'm not considering the possibility that multiple users were logging on
to the site one the same computer at the same time.

I think that firefox uses the same cookieset for all it's windows. For IE
it depends on how the new window is started.

In fact, the case where I have the most information about the problem (which
isn't much) is specifically on FireFox. But I still don't see how this could
be an issue.

Thanks.

Jonathan

[Hans Kesting]

on 25-9-2008, Jonathan Wood supposed :

Hans,

>What exactly do you mean by "multiple users logging in from the same
computer"?

I'm sorry. It's hard to know how to better state it than that. Unless you
clarify which part is unclear.

I gave some possibilities below

>If there is just one user at a time then there shouldn't be a problem.
If the first user closes his browser after he is finished, the session
cookie is forgotten. A new browser instance will use a new session.
When the first user logs out, you can destroy the session server side
(Session.Abandon).

Well, I don't know if it's a given that the browser was closed in between.
But even if it was, the cookie could remain after the browser is closed.
However, what if any data remains from that cookie is something I don't know.

The session cookie has no expiry-date so the browser treats it as a
temporary cookie. It does not get stored and disappears as soon as the
browser is closed.

>However, two users at *the same time* from the same computer could lead to
problems. The various browser windows could use the same cookie set. So
when a second user opens a new window, he could be automatically using the
session of the first user.

No, I'm not considering the possibility that multiple users were logging on
to the site one the same computer at the same time.

>I think that firefox uses the same cookieset for all it's windows. For IE
it depends on how the new window is started.

In fact, the case where I have the most information about the problem (which
isn't much) is specifically on FireFox. But I still don't see how this could
be an issue.

A guess: the first user did not log out and did not close his browser
window, but minimised it. The second user thought he started a fresh
instance of the browser but got a new window of the first instance,
with the session cookie (and thus the session) of the first user.

Thanks.

Jonathan

[Jonathan Wood]

Hans,

The session cookie has no expiry-date so the browser treats it as a
temporary cookie. It does not get stored and disappears as soon as the
browser is closed.

So what do you know about what happens if the browse is not closed? If the
user enters their username and password, can you think of any way they'd
still see data from the previous login?

A guess: the first user did not log out and did not close his browser
window, but minimised it. The second user thought he started a fresh
instance of the browser but got a new window of the first instance, with
the session cookie (and thus the session) of the first user.

But it seems quite certain that the second user (actually, it's one person
but I'll leave the details out) logged in using the Login control. Can you
think of any way that could happen without resetting the session?

Thanks.

Jonathan

[Cowboy \(Gregory A. Beamer\)]

What normally happens in these scenarios is user 2 (or user 1 logging in as
user 2) spawns a second browser instance using File >N (or control + N).
This puts the second instance in the process space for the first instance.
They then use the site under that context and switch back to context 1. Or
user 1 comes back and instance 1 is still open.

You see it a lot in testing and have to train testers to open a new browser
instance from the start menu. This is especially true in "manager testing".

In these cases, you are grabbing the same session.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://feeds.feedburner.com/GregoryBeamer#

or just read it:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************
"Hans Kesting" <ne*********@spamgourmet.comwrote in message
news:eF**************@TK2MSFTNGP02.phx.gbl...

Jonathan Wood explained :

>Thanks for the additional vote of confidence on Session.

There is a slight possibility that at least one of the users did log on
as other users. I will quiz them on if they might have logged on as the
users whose data they saw when they logged on as themselves.

I don't know that's the issue but I'll explore it. Is there as straight
forward way to allow multiple users to log on from the same computer?

Jonathan

What exactly do you mean by "multiple users logging in from the same
computer"?

If there is just one user at a time then there shouldn't be a problem.
If the first user closes his browser after he is finished, the session
cookie is forgotten. A new browser instance will use a new session.
When the first user logs out, you can destroy the session server side
(Session.Abandon).

However, two users at *the same time* from the same computer could lead to
problems. The various browser windows could use the same cookie set. So
when a second user opens a new window, he could be automatically using the
session of the first user.

I think that firefox uses the same cookieset for all it's windows. For IE
it depends on how the new window is started.

Hans Kesting

[Cowboy \(Gregory A. Beamer\)]

Open a browser instance. Log in.

Type Control + N. Log in in the second browser instance. As both are held in
the same process space, the second browser affects what goes on in the first
browser instance. Try it yourself.

There are a few ways to circumvent this, like forcing a session abandon when
the login page is hit, warning on log in (may hav eto be generic), but the
best way is called User Education.

If the user has to run as two people at one time (a manager testing your
work, for example), tell them to start both browser instances this way:

Start >Internet Explorer

Then each holds its own process space and they will not share session. They
can also use this method:

Start >Internet Explorer
Start >Firefox
Start >Opera
Start >Safari

and test four users at once.

Now that I know the issue, I am very familiar with it. And unless the user
logs out every time and forces session.abandon, it will continue to happen.

If this is your type of user, I would also disable the back button. The
easiest way is to use JavaScript to go forward one page in history. Then
back takes them back to the current page. There are other tricks to do this.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://feeds.feedburner.com/GregoryBeamer#

or just read it:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************
"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

Hans,

>The session cookie has no expiry-date so the browser treats it as a
temporary cookie. It does not get stored and disappears as soon as the
browser is closed.

So what do you know about what happens if the browse is not closed? If the
user enters their username and password, can you think of any way they'd
still see data from the previous login?

>A guess: the first user did not log out and did not close his browser
window, but minimised it. The second user thought he started a fresh
instance of the browser but got a new window of the first instance, with
the session cookie (and thus the session) of the first user.

But it seems quite certain that the second user (actually, it's one person
but I'll leave the details out) logged in using the Login control. Can you
think of any way that could happen without resetting the session?

Thanks.

Jonathan

[Jonathan Wood]

Heh, well "user education" is seldom an available option.

After talking with the client, it seems unlikely that the data he
inadvertantly saw was not for an account that he had recently logged into.
In fact, someone else reported the problem who does not have access to any
other accounts.

I'm officially completely baffled as to how this could ever happen.

Thanks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
"Cowboy (Gregory A. Beamer)" <No************@comcast.netNoSpamMwrote in
message news:u8***************@TK2MSFTNGP06.phx.gbl...

Open a browser instance. Log in.

Type Control + N. Log in in the second browser instance. As both are held
in the same process space, the second browser affects what goes on in the
first browser instance. Try it yourself.

There are a few ways to circumvent this, like forcing a session abandon
when the login page is hit, warning on log in (may hav eto be generic),
but the best way is called User Education.

If the user has to run as two people at one time (a manager testing your
work, for example), tell them to start both browser instances this way:

Start >Internet Explorer

Then each holds its own process space and they will not share session.
They can also use this method:

Start >Internet Explorer
Start >Firefox
Start >Opera
Start >Safari

and test four users at once.

Now that I know the issue, I am very familiar with it. And unless the user
logs out every time and forces session.abandon, it will continue to
happen.

If this is your type of user, I would also disable the back button. The
easiest way is to use JavaScript to go forward one page in history. Then
back takes them back to the current page. There are other tricks to do
this.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://feeds.feedburner.com/GregoryBeamer#

or just read it:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************
"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

>Hans,

>>The session cookie has no expiry-date so the browser treats it as a
temporary cookie. It does not get stored and disappears as soon as the
browser is closed.

So what do you know about what happens if the browse is not closed? If
the user enters their username and password, can you think of any way
they'd still see data from the previous login?

>>A guess: the first user did not log out and did not close his browser
window, but minimised it. The second user thought he started a fresh
instance of the browser but got a new window of the first instance, with
the session cookie (and thus the session) of the first user.

But it seems quite certain that the second user (actually, it's one
person but I'll leave the details out) logged in using the Login control.
Can you think of any way that could happen without resetting the session?

Thanks.

Jonathan

[my cats, Gag and yak]

Now that I know the issue, I am very familiar with it. And unless the user

logs out every time and forces session.abandon, it will continue to
happen.

In this situation, I use Session.RemoveAll()

Will that clear all session variables the same as Session.Abandon? I think
= yes.

What happens to a Session.Abandon(ed) visitor who continues to browse the
website after logging out?

Thank you

[Mark Rae [MVP]]

"my cats, Gag and yak" <mr********@comcast.netwrote in message
news:O5******************************@comcast.com. ..

>Now that I know the issue, I am very familiar with it. And unless the
user logs out every time and forces session.abandon, it will continue to
happen.

In this situation, I use Session.RemoveAll()

Will that clear all session variables the same as Session.Abandon? I
think = yes.

Yes, but there's more to it than that.

Session.Abandon includes Session.RemoveAll and *also* deletes the SessionID
created for the session. So, subsequent requests would create a new session
with a new SessionID.

Session.RemoveAll() will remove all the user defined session variables *but*
still keep the session intact.

What happens to a Session.Abandon(ed) visitor who continues to browse the
website after logging out?

See above...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[my cats, Gag and yak]

Am i correct in saying ( I am trying to understand ):

- a Session.RemoveAll() removes all session variable, the same as
Abandon
- however, whoever logs back in uses the same ID, all other info has
been dropped

- Session.Abandon nukes everything
- meaning it also creates a new session?

Thank you
"Mark Rae [MVP]" <ma**@markNOSPAMrae.netwrote in message
news:ON**************@TK2MSFTNGP04.phx.gbl...

"my cats, Gag and yak" <mr********@comcast.netwrote in message
news:O5******************************@comcast.com. ..

>>Now that I know the issue, I am very familiar with it. And unless the
user logs out every time and forces session.abandon, it will continue to
happen.

In this situation, I use Session.RemoveAll()

Will that clear all session variables the same as Session.Abandon? I
think = yes.

Yes, but there's more to it than that.

Session.Abandon includes Session.RemoveAll and *also* deletes the
SessionID created for the session. So, subsequent requests would create a
new session with a new SessionID.

Session.RemoveAll() will remove all the user defined session variables
*but* still keep the session intact.

>What happens to a Session.Abandon(ed) visitor who continues to browse the
website after logging out?

See above...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[Mark Rae [MVP]]

"my cats, Gag and yak" <mr********@comcast.netwrote in message
news:lu******************************@comcast.com. ..

[top-posting corrected]

>>>Now that I know the issue, I am very familiar with it. And unless the
user logs out every time and forces session.abandon, it will continue
to happen.

In this situation, I use Session.RemoveAll()

Will that clear all session variables the same as Session.Abandon? I
think = yes.

Yes, but there's more to it than that.

Session.Abandon includes Session.RemoveAll and *also* deletes the
SessionID created for the session. So, subsequent requests would create a
new session with a new SessionID.

Session.RemoveAll() will remove all the user defined session variables
*but* still keep the session intact.

>>What happens to a Session.Abandon(ed) visitor who continues to browse
the website after logging out?

See above...

Am I correct in saying ( I am trying to understand ):

- a Session.RemoveAll() removes all session variables, the same as Abandon
- however, whoever logs back in uses the same ID, all other info has been
dropped

- Session.Abandon nukes everything - meaning it also creates a new
session?

The Session object, like almost any other object, has some properties and
methods.

As regards the Session object specifically, it has a collection of
name/value pairs which you, the developer, can read from and write to. When
the Session object is first created (i.e. when someone visits your site for
the first time), some of these name/value pairs are created automatically
for you, including the ID. You can query these initial name/value pairs, but
you can't remove them. However, you can add your own name/value pairs as
your application requires.

The Session object has a Remove() method. This allows you to remove one of
the individual name/value pairs (which you had previously added) from the
collection of name/value pairs.

The Session object has a RemoveAll() method. This allows you to remove all
of the individual name/value pairs (which you had previously added) from the
collection of name/value pairs. However, it does not destroy the Session
object itself, so all the read-only name/value pairs (e.g. the Session ID)
remain. If the user does not navigate away from your site or close their
browser, the Session object remains until / unless it times out naturally.

The Session object has an Abandon() method. This firstly calls the
RemoveAll() method, and then it tears down the session itself by destroying
the Session object. Therefore, if the user continues to try to use your
site, a new Session object will be created. Depending on how you have
designed and implemented the security on your site, the user will be
required to log in again.
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[my cats, Gag and yak]

thank you for your explaination!

"Mark Rae [MVP]" <ma**@markNOSPAMrae.netwrote in message
news:uA**************@TK2MSFTNGP05.phx.gbl...

"my cats, Gag and yak" <mr********@comcast.netwrote in message
news:lu******************************@comcast.com. ..

[top-posting corrected]

>>>>Now that I know the issue, I am very familiar with it. And unless the
user logs out every time and forces session.abandon, it will continue
to happen.

In this situation, I use Session.RemoveAll()

Will that clear all session variables the same as Session.Abandon? I
think = yes.

Yes, but there's more to it than that.

Session.Abandon includes Session.RemoveAll and *also* deletes the
SessionID created for the session. So, subsequent requests would create
a new session with a new SessionID.

Session.RemoveAll() will remove all the user defined session variables
*but* still keep the session intact.

What happens to a Session.Abandon(ed) visitor who continues to browse
the website after logging out?

See above...

Am I correct in saying ( I am trying to understand ):

- a Session.RemoveAll() removes all session variables, the same as
Abandon
- however, whoever logs back in uses the same ID, all other info has been
dropped

- Session.Abandon nukes everything - meaning it also creates a new
session?

The Session object, like almost any other object, has some properties and
methods.

As regards the Session object specifically, it has a collection of
name/value pairs which you, the developer, can read from and write to.
When the Session object is first created (i.e. when someone visits your
site for the first time), some of these name/value pairs are created
automatically for you, including the ID. You can query these initial
name/value pairs, but you can't remove them. However, you can add your own
name/value pairs as your application requires.

The Session object has a Remove() method. This allows you to remove one of
the individual name/value pairs (which you had previously added) from the
collection of name/value pairs.

The Session object has a RemoveAll() method. This allows you to remove all
of the individual name/value pairs (which you had previously added) from
the collection of name/value pairs. However, it does not destroy the
Session object itself, so all the read-only name/value pairs (e.g. the
Session ID) remain. If the user does not navigate away from your site or
close their browser, the Session object remains until / unless it times
out naturally.

The Session object has an Abandon() method. This firstly calls the
RemoveAll() method, and then it tears down the session itself by
destroying the Session object. Therefore, if the user continues to try to
use your site, a new Session object will be created. Depending on how you
have designed and implemented the security on your site, the user will be
required to log in again.
--
Mark Rae
ASP.NET MVP
http://www.markrae.net