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

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









"Marina Levit [MVP]" <someone@xxxxxxxxxx> wrote in message
news:O5Ha8vs8GHA.4708@xxxxxxxxxxxxxxxxxxxxxxx
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.

"BillE" <belgie@xxxxxxxxxxx> wrote in message
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?
    ... The user selects a Customer in a browser and enters an order. ... and the same session variables. ... You can research session state very thoroughly without finding any ... with the use of Session Variables? ...
    (microsoft.public.dotnet.framework.aspnet)
  • 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?
    ... the use of Session Variables? ... I think it is a basic role of documentation to point out potential ... integrity of an application which relies on session state is COMPLETELY ... Such that developers seeking basic guidance will not fail to ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: public static/shared read only properties in global.asax
    ... I am trying to simplify the use of the Session, Application and Cache ... Most of our developers are just breaking ... >> Public Shared ReadOnly Property TitleAs String ...
    (microsoft.public.dotnet.framework)
  • 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)