Session Variables - why aren't novice developers warned?



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: window.open() and unwanted session state (urgent)
    ... popup.domain.com should work unless the cookie domain is *.domain.com ... Tomasz J wrote: ... But now I have an opposite problem: how to open a new browser window so it *does not* share the session state with the first window? ...
    (microsoft.public.dotnet.framework.aspnet)
  • RE: window.open() and unwanted session state (urgent)
    ... Could you please depict more about why you need to make the new browser ... window *does not* share the session state with the first (parent) window? ... If you need to do this because session state locking, ...
    (microsoft.public.dotnet.framework.aspnet)
  • RE: Forms authentication issue
    ... the new window should definitely share Session state with the ... For example, I login, click a link to display a report that opens a new ... the result is that a my Login page opens in a new browser window. ...
    (microsoft.public.dotnet.framework.aspnet)
  • State managment
    ... A user can navigate through the stored records. ... the user opens a new browser window from the existing one and enters another ... previous window in the session state and both windows display the same ... results though the search criteria look different. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Session Variables - why arent novice developers warned?
    ... child window. ... which shares the same Session ID as the parent window, ... integrity of an application which relies on session state is COMPLETELY ... Why aren't developers warned of this while the basics of ASP.NET ...
    (microsoft.public.dotnet.framework.aspnet)

Loading