Session Variables - why aren't novice developers warned?

  • Thread starter Thread starter BillE
  • Start date Start date
B

BillE

When a user opens a new IE browser window using File-New-Window the
integrity of an application which relies on session state is COMPLETELY
undermined. Anyone who overlooks the fact that File-New-Window creates an
instance of IE in the same process with the same SessionID as the parent
window is in big trouble. This fundamentally restricts the usefullness of
using session state management.



I probably missed it somewhere - can someone please help me find where in
the Visual Studio 2005 documentation this pitfall is PLAINLY mentioned?
Such that developers seeking basic guidance will not fail to note the
warning? There are articles which explain elementary concepts such as how
to create a session variable, without pointing out this serious hazard.



I have read the articles entitled Session State Overview, Session
Identifiers, Session State Events, etc. and I can't find this trap openly
described. For example, the article ASP.NET State Management
Recommendations identifies only performance considerations in the
Disadvantage of Using Session State section.



Why aren't developers warned of this while the basics of ASP.NET development
are being explained?

I agree that the injudicious use of global variables in any type of
application is sloppy and can incur pitfalls. However, in most types of
applications global variables are limited in scope to the instance of the
application. If there are multiple instances of the same application open
on one machine, each instance has its own scope. I think many (most?) asp
developers may have naive expectations that this is the case when using
session variables in an asp application hosted by Internet Explorer. I did.



-Bill
 
Bill,
Unfortunatley, that's not the job of documentation. The docs are
meant to instruct on a particular subject, not to speculate on the pros and
cons. There are plenty of articles out there as well as books that discuss
these pros and cons in-depth. The pros and cons have been discussed now for
the better part of a decade so the information is there, it's just not the
place of the documentation to inform you of comparisons with other
technologies and with the pros and cons. It's the docs job simply to explain
and instruct on the particular topic. Before attempting to implement
something new, it's always useful to seek out some of the info that's out
there on a topic. For example, there are plenty of articles out there on
session variables, how to use them in web-farms, high-jacking of cookiless
sessions, etc., as developers we just need to seek them out as the docs are
never the be-all and end-all on a subject.
 
Thanks for your response Mark.

I would ask why it is not a fundamental role of the Visual Studio
documentation to identify the potentially damaging risks associated with the
use of Session Variables?

I think it is a basic role of documentation to point out potential pitfalls
and provide guidance on correct usage.

Thanks!
Bill
 
I am sure we can all identify hundreds of ways that a novice could screw up
their entire application. It does not mean that MS can identify or document
all of them.

It is best to not make assumptions and to research how things work before
relying on them. That is what the job of a developer is - and sometimes you
can only learn by making mistakes. You don't put the blame on others.
 
Marina, I certainly agree with everything you say - particularly in not
putting the blame on others!

However, I also feel that this potential hazard is severe enough that it
should be explicitly identified as a disadvantage. Worst of all, it is a
shortcoming that can go undetected, compromising data until finally noticed.
I expect there may be countless ASP applications deployed which are silently
adding orders to the wrong customer and the like because the developer did
not stumble across this issue.

You can research session state very thoroughly without finding any reference
to this damaging problem.

Respectfully, can you tell me where this issue is raised in MSDN, for
example, so that a developer responsibly researching the use of session
state prior to implementation would be likely to find it? Search on
"session state disadvantages" for example - performance is the only
disadvantage mentioned.

Thanks!
Bill
 
I expect there may be countless ASP applications deployed which are
silently adding orders to the wrong customer and the like because the
developer did not stumble across this issue.
Click to expand...

I feel that, if that were indeed the case, then it would be down to woefully
inadequate (more like non-existent!) testing...
You can research session state very thoroughly without finding any
reference to this damaging problem.
Click to expand...

http://www.google.co.uk/search?sour...&rls=GGLG,GGLG:2006-28,GGLG:en&q=IsNewSession
http://www.google.co.uk/search?sour...G:2006-28,GGLG:en&q=IsNewSession+"new+window"
 
Also this is a browser dependant problem, not really something caused by VS/
ASP.NET. Plus this is not necessarily a problem for most of us...

What is your scenario ?
 
Possibly, Mark, but I think that even thorough testers might overlook the
possibility of clicking File-New-Window in Internet Explorer if they weren't
previously aware that it could cause problems. After all, they are testing
the application, not the behavior of Internet Explorer!

Which returns to the main point - how is a developer / tester to become
aware of this pitfall? The only way I can find reference to the problem it
is by specifically searching on something which implies prior knowledge of
the problem (like "Internet Explorer File New Window").

I appreciate the dialog.

Bill
 
Possibly, Mark, but I think that even thorough testers might overlook the
possibility of clicking File-New-Window in Internet Explorer if they
weren't previously aware that it could cause problems. After all, they
are testing the application, not the behavior of Internet Explorer!
Click to expand...

Then they need to be testing the application under the various different
functional scenarios of the platform it's running under...
Opening a new window is just one of these. Same as the effect of turning
JavaScript off, etc...
Which returns to the main point - how is a developer / tester to become
aware of this pitfall?
Click to expand...

Trial and error. Every new runtime scenario encountered by the development /
testing team gets added to the knowledge pool...
 
Hi Patrice

Take a Customers/Orders model, ala Northwind.

The user selects a Customer in a browser and enters an order. Assume they
select "Cactus Comidas par a llevar". The current customer is stored in a
session variable Session("CustomerID") = "CACTU". The customer name is
displayed in the web form.

The user then clicks File-New-Window and opens a new instance of IE in the
same process. Since it is in the same process, it shares the same sessionID
and the same session variables.

In the new window the user opens a new customer, "Around the Horn". The
session varaible is Session("CustomerID") = "AROUT". "Around the Horn" is
displayed in the web form.

If the user returns to the first, parent browser window, the customer which
is displayed is "Cactus Comidas par a llevar". But when an order is
entered, it is associated with the session variable in the child window
instead. The order is placed for the wrong customer. No error is
displayed, nobody knows there is a problem until the screaming starts.
 
Perhaps. My assertion, however, is that the documentation should identify
this potential problem in the first place.
 
Again, there are hundreds of ways that a developer that does not know any
better can cause major problems in an application.

Additionally, you cannot claim this is a disadvantage in any way. For many
applications (and probably more then not), it is actually an advantage.
Developers want the session to be preserved when a new browser is opened
from an existing browser session. This avoids having to have people log in
again, and allows the user to continue work in the application. Many times
this is exactly what people want.

You don't want this behavior - but it doesn't make it a bug, or a
disadvantage, or anything else. It just means, this is how things work. And
as with anything, it's going to fit perfectly with some applications, and
not with others. Just because it's not the way you want it, doesn't mean no
one else wants it that way, or that it is a shortcoming.

In any case, all this has more to do with the fact that it is the browser
maintaining the session cookies. And when you open up a new browser from an
existing one, the new window shares those session cookies with the original.
This really has nothing to do with ASP.NET - it is the browser doing this.
Different browsers can if they choose to, implement this differently.

And as someone pointed out, the most basic QA or test of the application
should have revealed this immediately.
 
this problem falls into the same catergory, as the following problems

1) browser refresh - not handling a refresh of the page
2) double submit problem - not handling double second click while waiting
for render
3) use of static/vb modules to store session data
4) bloated viewstate
5) not understanding the page lifecyyle - page load fires on render and
postback, and before event firing.

all this problems are pretty easy to predict if the dev takes the time to
lean how a web applications work and its stateless nature.

-- bruce (sqlwork.com)
 
I appreciate your input, and again I can't dispute anything you say.

I think, though, that you have misunderstood my position. I have no
complaint about the way IE behaves, and I don't claim this behavior is a
bug, or that IE shouldn't behave this way. I didn't state that I "don't
want this behavior".

I am only pointing out that the documentation specifically presents a
methodology for using session variables, without explicitly identifying a
very dangerous outcome which may result when the session variables are used
as presented in the documentation.

Very diligent research will fail to reveal this potential pitfall. Again, I
would like to have it pointed out to me where the documentation, MSDN, or
any other resource would provide this information to a developer who is not
already aware of it.

My real intent is to make sure that people who utilize this newsgroup as a
resource will become aware of this. I expect that there are many developers
who read these posts who are not aware that their application may be
compromised if a user clicks File-New-Window!

Granted that a seasoned developer and astute tester will not commit this
error, or will immediately recognize the error. But this error is so
likely, so easily undetected, and so dangerous, that I think it should be
very clearly identified in the documentation and anywhere else session state
management is discussed.

Thanks again for indulging me.
Bill
 
Bruce -
You are correct - all the problems you mention are "easy to predict if the
dev takes the time to
lean how a web applications work and its stateless nature".

But knowing "how a web applications work and its stateless nature" does not
predict that the IE action File-New-Window will open a new browser window
which shares the same Session ID as the parent window, and replaces the
content of session variables with damaging consequences.

Thanks for your response, Bruce.
Bill
 
Not only is this behavior pretty predictable but it can be quite
useful. I often use session to pass data to a page that I open in a
child window (through JavaScript). It's true that the scenario you
mention is going to be easy to miss in testing... but how often is a
single userr going to log in under one account in one window, begin a
transaction, not complete it, log in as another user in a different
window... you can't expect the documentation to warn you of every
possible pitfall.
 
Hi Russell -

I'm not sure why this behavior is predicatable. How did you learn of it?

I realized it when I inherited a VB6 web class project, and while
interviewing users for upgrade requirements I was told that sometimes data
entry was save to the wrong entity.

I do understand how it can be useful.

I agree that the documentation should not warn of every possible pitfall.

However, I think there is a responsibility to caution against Probable
pitfalls which can cause major problems.

I think that the usefullness of session variables is very limited because of
this behavior. Since session variables are so convenient, it is very
tempting to use them indiscrimantly if the developer is unaware of this
pitfall.

Thanks!
Bill
 
BillE said:
Possibly, Mark, but I think that even thorough testers might overlook the
possibility of clicking File-New-Window in Internet Explorer if they weren't
previously aware that it could cause problems. After all, they are testing
the application, not the behavior of Internet Explorer!

Which returns to the main point - how is a developer / tester to become
aware of this pitfall? The only way I can find reference to the problem it
is by specifically searching on something which implies prior knowledge of
the problem (like "Internet Explorer File New Window").
Click to expand...

You see it as a pitfall - others may see it as a boon. For instance, we
want to provide a link to a dynamically generated booklet for the
client which will open in a new window. In that case, we definitely
*do* want the same session to be shared between the windows, otherwise
we have to go and invent something new for ourselves, or have to expose
potentially sensitive information in e.g. the query string, in order to
find the right data.

Damien
 
Damien -

I fully agree that this is appropriate behavior in IE. I just think it
should be mentioned somewhere where it will be seen. How did you learn of
this?

My point is that this is such a potentially serious problem, and so likely
to occur, that I don't understand why it is not documented somewhere in MSDN
or the VS documentation. I can only find reference to it in forums where
someone has found out the hard way.

No basic explanation of the use of session variables that I can find
counsels the developer about the risk of a user compromising the application
completely by using Ctrl-N.

Thanks!
Bill
 
Back
Top