Re: Session Variables - why aren't novice developers warned?

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.



"Patrice" <scribe@xxxxxxxx> wrote in message
news:%23p$aNUs8GHA.1496@xxxxxxxxxxxxxxxxxxxxxxx
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 ?

--
Patrice

"BillE" <belgie@xxxxxxxxxxx> a écrit dans le message de news:
et7L5Es8GHA.2120@xxxxxxxxxxxxxxxxxxxxxxx
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


"Marina Levit [MVP]" <someone@xxxxxxxxxx> wrote in message
news:O%23AAO2r8GHA.940@xxxxxxxxxxxxxxxxxxxxxxx
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.

"BillE" <belgie@xxxxxxxxxxx> wrote in message
news:%23L4PAyr8GHA.4116@xxxxxxxxxxxxxxxxxxxxxxx
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


"Mark Fitzpatrick" <markfitz@xxxxxxxxxx> wrote in message
news:%23i1s3or8GHA.4572@xxxxxxxxxxxxxxxxxxxxxxx
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.


--
Hope this helps,
Mark Fitzpatrick
Former Microsoft FrontPage MVP 199?-2006

"BillE" <belgie@xxxxxxxxxxx> wrote in message
news:OZ2foZr8GHA.2288@xxxxxxxxxxxxxxxxxxxxxxx
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


"GroupReader" <newsgroups_01@xxxxxxxxxxx> wrote in message
news:1161148121.175510.124660@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
You'll have these issues *any* time you use global variables in
*any*
type of application. It's best to use local variables whenever
possible. In asp.net this translates to passing your variables
around
from form to form. Use querystring variables or form variables
instead. Sorry I don't have a decent solution, but one more
thought:
I think your issue may get worse when IE7 introduces "tabbed
browsing"... which makes it much easier to "open new windows".
Maybe
there's an IE setting that tells IE to start a new session when a
new
window is opened(?)















.

Relevant Pages

  • Re: Session Variables - why arent novice developers warned?
    ... very dangerous outcome which may result when the session variables are used ... Developers want the session to be preserved when a new browser ... You can research session state very thoroughly without finding any ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Warning - AVOID SESSION VARIABLES
    ... inevitably occur if session variables are not used very carefully. ... convenience of session variables to persist values (like Customer ID) ... In fact from beginning NO browser window is unique, that's http/tcp, no ...
    (microsoft.public.dotnet.framework.aspnet)
  • Database Access vs Turning on SessionState
    ... My asp application currently does not rely on session state at all, ... The function that I need to implements include a customer specific price ... trip access to the database server. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Warning - AVOID SESSION VARIABLES
    ... It is more a practices problem than a session problem. ... BOTH WINDOWS SHARE THE SAME SESSION VARIABLES. ... second window, it is also changed in the first window. ... browser using Ctrl-N, changed the customer in the new window, and then ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: I keep losing session state on Prod server
    ... > back in the Classic ASP days, reseting our session. ... I built a simple app that uses session variables on my DEV ... >>> and that "Preserve Session State" was checked. ...
    (microsoft.public.dotnet.framework.aspnet)
Loading