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 s
ing 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
Di
vantage 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@dotnet.itags.org.hotmail.com> wrote in message
news:1161148121.175510.124660@dotnet.itags.org.b28g2000cwb.googlegroups.com...
> 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(?)
>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 s
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 s
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@.datamti.com> wrote in message
news:OZ2foZr8GHA.2288@.TK2MSFTNGP05.phx.gbl...
> 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 s
ing 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
> Di
vantage 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@.hotmail.com> wrote in message
> news:1161148121.175510.124660@.b28g2000cwb.googlegroups.com...
>
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@.fitzme.com> wrote in message
news:%23i1s3or8GHA.4572@.TK2MSFTNGP02.phx.gbl...
> 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 s
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
> s
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@.datamti.com> wrote in message
> news:OZ2foZr8GHA.2288@.TK2MSFTNGP05.phx.gbl...
>
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@.datamti.com> wrote in message
news:%23L4PAyr8GHA.4116@.TK2MSFTNGP03.phx.gbl...
> 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@.fitzme.com> wrote in message
> news:%23i1s3or8GHA.4572@.TK2MSFTNGP02.phx.gbl...
>
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 di
vantage. 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 di
vantages" for example - performance is the only
di
vantage mentioned.
Thanks!
Bill
"Marina Levit [MVP]" <someone@.nospam.com> wrote in message
news:O%23AAO2r8GHA.940@.TK2MSFTNGP03.phx.gbl...
>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@.datamti.com> wrote in message
> news:%23L4PAyr8GHA.4116@.TK2MSFTNGP03.phx.gbl...
>
"BillE" <belgie@.datamti.com> wrote in message
news:et7L5Es8GHA.2120@.TK2MSFTNGP03.phx.gbl...
> 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.
I feel that, if that were indeed the case, then it would be down to woefully
inadequate (more like non-existent!) testing...
> You can research session state very thoroughly without finding any
> reference to this damaging problem.
http://www.google.co.uk/search?sour...&q=IsNewSession
http://www.google.co.uk/search?sour...22new+window%22
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@.datamti.com> a crit dans le message de news:
et7L5Es8GHA.2120@.TK2MSFTNGP03.phx.gbl...
> 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 di
vantage. 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 di
vantages" for example - performance is the only
> di
vantage mentioned.
> Thanks!
> Bill
>
> "Marina Levit [MVP]" <someone@.nospam.com> wrote in message
> news:O%23AAO2r8GHA.940@.TK2MSFTNGP03.phx.gbl...
>
Possibly, Mark, but I think that even thorough testers might overlook the
possibility of clicking File-New-Window in Internet Explorer if they weren't
previously aware that it could cause problems. After all, they are testing
the application, not the behavior of Internet Explorer!
Which returns to the main point - how is a developer / tester to become
aware of this pitfall? The only way I can find reference to the problem it
is by specifically searching on something which implies prior knowledge of
the problem (like "Internet Explorer File New Window").
I appreciate the dialog.
Bill
"Mark Rae" <mark@.markNOSPAMrae.com> wrote in message
news:eB$KDOs8GHA.4644@.TK2MSFTNGP04.phx.gbl...
> "BillE" <belgie@.datamti.com> wrote in message
> news:et7L5Es8GHA.2120@.TK2MSFTNGP03.phx.gbl...
>
> I feel that, if that were indeed the case, then it would be down to
> woefully inadequate (more like non-existent!) testing...
>
> http://www.google.co.uk/search?sour...&q=IsNewSession
> http://www.google.co.uk/search?sour...22new+window%22
>
"BillE" <belgie@.datamti.com> wrote in message
news:uiKMIWs8GHA.4012@.TK2MSFTNGP04.phx.gbl...
> Possibly, Mark, but I think that even thorough testers might overlook the
> possibility of clicking File-New-Window in Internet Explorer if they
> weren't previously aware that it could cause problems. After all, they
> are testing the application, not the behavior of Internet Explorer!
Then they need to be testing the application under the various different
functional scenarios of the platform it's running under...
Opening a new window is just one of these. Same as the effect of turning
JavaScript off, etc...
> Which returns to the main point - how is a developer / tester to become
> aware of this pitfall?
Trial and error. Every new runtime scenario encountered by the development /
testing team gets added to the knowledge pool...
this problem falls into the same catergory, as the following problems
1) browser refresh - not handling a refresh of the page
2) double submit problem - not handling double second click while waiting
for render
3) use of static/vb modules to store session data
4) bloated viewstate
5) not understanding the page lifecyyle - page load fires on render and
postback, and before event firing.
all this problems are pretty easy to predict if the dev takes the time to
lean how a web applications work and its stateless nature.
-- bruce (sqlwork.com)
"BillE" <belgie@.datamti.com> wrote in message
news:OZ2foZr8GHA.2288@.TK2MSFTNGP05.phx.gbl...
> 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 s
ing 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
> Di
vantage 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@.hotmail.com> wrote in message
> news:1161148121.175510.124660@.b28g2000cwb.googlegroups.com...
>
