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



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: Storing Controls as session variables?
    ... Don't forget that, if your clients browser disables cookies in his computer, ... session will not be used by him. ... pros and cons? ...
    (microsoft.public.dotnet.framework.aspnet)
  • RE: Trouble with huge amount of State Server Sessions Timed out
    ... "Unable to serialize the session state. ... > State Service or SQL Server can be memory intensive depending on the types ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: IHttpAsyncHandler problem
    ... My guess is that it's not the page you're waiting for, but the lock on the session state. ... It seems the Asp.Net ThreadPool thread used by the first tab is ... AsyncRequestState reqState = result; ...
    (microsoft.public.dotnet.framework.aspnet)
  • 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: Session Variables - why arent novice developers warned?
    ... You can research session state very thoroughly without finding any ... I think it is a basic role of documentation to point out potential ... Such that developers seeking basic guidance will not fail ...
    (microsoft.public.dotnet.framework.aspnet)