Warning - AVOID SESSION VARIABLES

[BillE]

Some ASP.NET applications use Session Variables extensively to maintain
state.

These should be re-written to use viewstate, hidden fields, querystring,
etc. instead.

This is because if a user opens a new IE window with Ctrl-N or
File-New-Window, BOTH WINDOWS SHARE THE SAME SESSION VARIABLES. This cannot
be prevented.

This means that if you change the value of a session variable in the second
window, it is also changed in the first window.

Session variables should only be used if this behavior is recognized and
compensated for.

I inherited a VB6 web class application which uses session variables
extensively. Users told me that sometimes orders were being added for the
wrong customer. I found that this occured when they opened a second browser
using Ctrl-N, changed the customer in the new window, and then returned to
the first window to add an order. They didn't realize that the customer
displayed in the first window was no longer consistent with the customer ID
stored in the shared CustomerID session variable.

 

[Cowboy \(Gregory A. Beamer\)]

This is a long known issue. If a new browser is pulled from the old browser,
both have the same name, which means they share session. You can prevent
this by checking user input and ensuring you are dealing with the same
record. It is more a practices problem than a session problem.

On the other hand, I agree that you should keep page specific stuff in the
page. ViewState is a good option here.

 

[Mark Rae]

On the other hand, I agree that you should keep page specific stuff in the
page. ViewState is a good option here.

That's just common sense, surely...?

 

[BillE]

I think that the only way to ensure you are dealing with the same record is
to avoid session variables.

For example, if you are using Master pages, as far as I can tell, this means
that a customer ID must be passed by query string for GET requests, and by
hidden fields for POST requests when a new child page is being called.

Is this an accurate statement?

Thanks
-Bill

 

[Mark Rae]

For example, if you are using Master pages, as far as I can tell, this
means that a customer ID must be passed by query string for GET requests,
and by hidden fields for POST requests when a new child page is being
called.

Is this an accurate statement?

Not im my experience - I use ViewState all the time within ContentPages...

 

[BillE]

Do your content pages initially receive parameters from query strings or
hidden fields?

 

[Mark Rae]

Do your content pages initially receive parameters from query strings or
hidden fields?

Neither - they most often receive them from a Session variable which is read
and destroyed on Page_Load, surrounded by if (!IsPostBack). If the user
tries to open the page directly either by typing the URL into the address
bar directly or clicking File, New, that Session variable won't be there, so
the process will not continue. Instead, the user will be redirected to an
error page telling them not to do what they tried to do...

 

[BillE]

Good solution. Thanks!

Neither - they most often receive them from a Session variable which is
read and destroyed on Page_Load, surrounded by if (!IsPostBack). If the
user tries to open the page directly either by typing the URL into the
address bar directly or clicking File, New, that Session variable won't be
there, so the process will not continue. Instead, the user will be
redirected to an error page telling them not to do what they tried to
do...

 

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

Your concern is valid, but this isn't really a problem with session
variables. It's more a question of where you should store different kind
of state.

Session variables are suitable for values that remain the same
throughout the session, like the id of the logged in user. The id of the
customer that you are currently viewing is something that should follow
the page rather than the session.

If you would store session specific data in an application variable,
that would of course be a problem if there ever is more than one session
active at the same time. In the same way, if you store page specific
data in a session variable, there is a problem if one user has more than
one page open at the same time.

 

[BillE]

Well put.

Unfortunately, I suspect there are many developers who use the convenience
of session variables to persist values (like Customer ID) without realizing
that a user will eventually compromise the application with a simple action
like Ctrl-N.

The only time I see this risk mentioned is in posts in newsgroups and forums
from distressed and perplexed developers!

Thanks
Bill

 

[Steve C. Orr [MVP, MCSD]]

Just because session variables are bad to use in certain situations does not
mean that they are always bad. Just like virtually every development
technique, there are trade offs that should be carefully weighed before
deciding the course on which to embark.

When I first saw the title of your post I thought you were going to rave
about what a problem session variables can be when it comes to scalability,
but you didn't even mention that.

Despite such issues, its hard to deny what a convenient development time
saver session variables can be.

 

[Edwin Knoppert]

Unfortunately, I suspect there are many developers who use the convenience

of session variables to persist values (like Customer ID) without
realizing that a user will eventually compromise the application with a
simple action like Ctrl-N.

I can really hear from this sentence that you really expected a(ny) session
to be unique.
In fact from beginning NO browser window is unique, that's http/tcp, no
window is unique.

You can only mess with html to try it to make unique.
But you should always bear in mind that one can have multiple windows open
and that you'll (possibly) not be able to distinguish them.. ever..

Messing wiht hidden controls/viewstate.. o well it's static but an unique
value injected..?
Saving the html and open it again also loads any previous ID you managed, so
that fails as well.

 

[dgk]

Neither - they most often receive them from a Session variable which is read
and destroyed on Page_Load, surrounded by if (!IsPostBack). If the user
tries to open the page directly either by typing the URL into the address
bar directly or clicking File, New, that Session variable won't be there, so
the process will not continue. Instead, the user will be redirected to an
error page telling them not to do what they tried to do...

I'm still waiting for the Microsoft Electroshock Feedback Keyboard.

 

[dgk]

Just because session variables are bad to use in certain situations does not
mean that they are always bad. Just like virtually every development
technique, there are trade offs that should be carefully weighed before
deciding the course on which to embark.

When I first saw the title of your post I thought you were going to rave
about what a problem session variables can be when it comes to scalability,
but you didn't even mention that.

Despite such issues, its hard to deny what a convenient development time
saver session variables can be.

I'm new to ASP.NET development so I appreciate the whole thread, and
the one it descended from. I didn't realize that folks open up new
browser windows that share the session state so I will code for that.

How does IE7's tabbed windows (and Firefox) work - do those share the
session or start a new one?

 

[BillE]

dgk-

You are the intended audience for my post.

Thanks
Bill

 

[BillE]

The VS 2005 documentation clearly warns about performance issues in ASP.NET
State Management Recommendations (Disadvantage of Using Session State), so I
don't need to rave about it.

I agree with you on every point - I just want novice developers to know
about the trade-offs! How are they to know? This behavior is not mentioned
in any documentation I can find.

Thanks!
Bill

 

[BillE]

Hi Edwin -

I will reiterate that I have no objection to any behavior of ASP, IE, or
Session State.

My point is to alert developers to this potential pitfall. This will
inevitably occur if session variables are not used very carefully. When it
occurs, it will go possibly go undetected until significant damage has been
done.

Thanks
-Bill

 

[BillE]

I believe the same behavior will occur in IE7 tabbed windows and in Firefox.

-Bill

 

[Registered User]

Some ASP.NET applications use Session Variables extensively to maintain
state.

These should be re-written to use viewstate, hidden fields, querystring,
etc. instead.
OK....
This is because if a user opens a new IE window with Ctrl-N or
File-New-Window, BOTH WINDOWS SHARE THE SAME SESSION VARIABLES. This cannot
be prevented.
Yep...
This means that if you change the value of a session variable in the second
window, it is also changed in the first window.

Session variables should only be used if this behavior is recognized and
compensated for.

There are many different things can replace 'session variables' in the
sentence above.

I inherited a VB6 web class application which uses session variables
extensively. Users told me that sometimes orders were being added for the
wrong customer. I found that this occured when they opened a second browser
using Ctrl-N, changed the customer in the new window, and then returned to
the first window to add an order. They didn't realize that the customer
displayed in the first window was no longer consistent with the customer ID
stored in the shared CustomerID session variable.

Walk through the way you and the user think it should work and try to
figure how the road should fork when a second, third, fourth, ...
browser is opened. How does the server reconcile the existence of the
new client? How are authentication tickets to be handled? Is the new
client data co-joined to the original client's data or is a completely
different entity considered? When a user logs out does the logout
encompass all open browsers or just the one instance? Keep asking
questions and the additional complexity starts to resemble Hydra.

That the user "didn't realize" how things work suggests training
issues. It always helps to know how computers work. There may be
design and implementation issues as well.

regards
A.G.

 

[BillE]

The primary issue was that the developer didn't know that Ctrl-N opened a
new window which shared the same session variables as the parent window, and
didn't code to allow for this.