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

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?
    ... Developers want the session to be preserved when a new browser is opened ... You can research session state very thoroughly without finding any ... I think it is a basic role of documentation to point out potential ...
    (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?
    ... use of Session Variables? ... I think it is a basic role of documentation to point out potential pitfalls ... integrity of an application which relies on session state is COMPLETELY ... Such that developers seeking basic guidance will not fail to note the ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Primary/non primary sessions
    ... > amogh wrote: ... >> non-migratable parent session. ... documentation does NOT constitute 'well documented'. ...
    (comp.databases.oracle.server)
  • Re: Memory Mapping Anomaly
    ... internally (we often write our own suplementary documentation on stuff like ... I can, as a non privileged user, open an object from one session when the ... This is done by simply prefixing with the session id of the session names ... It is not documented and just mentioning NOT to use it ...
    (microsoft.public.win32.programmer.kernel)