Session Variables - why aren't novice developers warned?

[BillE]

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" <ne***********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.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(?)

[Mark Fitzpatrick]

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" <be****@datamti.comwrote in message
news:OZ**************@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 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" <ne***********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.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(?)

[BillE]

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" <ma******@fitzme.comwrote in message
news:%2****************@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 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" <be****@datamti.comwrote in message
news:OZ**************@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 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" <ne***********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googleg roups.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(?)

[Marina Levit [MVP]]

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" <be****@datamti.comwrote in message
news:%2****************@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" <ma******@fitzme.comwrote in message
news:%2****************@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 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" <be****@datamti.comwrote in message
news:OZ**************@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 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" <ne***********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.google groups.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(?)

[BillE]

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]" <so*****@nospam.comwrote in message
news:O%***************@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" <be****@datamti.comwrote in message
news:%2****************@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" <ma******@fitzme.comwrote in message
news:%2****************@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 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" <be****@datamti.comwrote in message
news:OZ**************@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 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" <ne***********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googl egroups.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(?)
>

[Mark Rae]

"BillE" <be****@datamti.comwrote in message
news:et**************@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?sourc...q=IsNewSession
http://www.google.co.uk/search?sourc...2new+window%22

[Patrice]

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" <be****@datamti.coma écrit dans le message de news:
et**************@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 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]" <so*****@nospam.comwrote in message
news:O%***************@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" <be****@datamti.comwrote in message
news:%2****************@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" <ma******@fitzme.comwrote in message
news:%2****************@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
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" <be****@datamti.comwrote in message
news:OZ**************@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 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" <ne***********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.goog legroups.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(?)
>>
>
>

[BillE]

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" <ma**@markNOSPAMrae.comwrote in message
news:eB**************@TK2MSFTNGP04.phx.gbl...

"BillE" <be****@datamti.comwrote in message
news:et**************@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?sourc...q=IsNewSession
http://www.google.co.uk/search?sourc...2new+window%22

[Mark Rae]

"BillE" <be****@datamti.comwrote in message
news:ui**************@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...

[BillE]

Hi Patrice

Take a Customers/Orders model, ala Northwind.

The user selects a Customer in a browser and enters an order. Assume they
select "Cactus Comidas par a llevar". The current customer is stored in a
session variable Session("CustomerID") = "CACTU". The customer name is
displayed in the web form.

The user then clicks File-New-Window and opens a new instance of IE in the
same process. Since it is in the same process, it shares the same sessionID
and the same session variables.

In the new window the user opens a new customer, "Around the Horn". The
session varaible is Session("CustomerID") = "AROUT". "Around the Horn" is
displayed in the web form.

If the user returns to the first, parent browser window, the customer which
is displayed is "Cactus Comidas par a llevar". But when an order is
entered, it is associated with the session variable in the child window
instead. The order is placed for the wrong customer. No error is
displayed, nobody knows there is a problem until the screaming starts.

"Patrice" <sc****@chez.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

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" <be****@datamti.coma écrit dans le message de news:
et**************@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 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]" <so*****@nospam.comwrote in message
news:O%***************@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" <be****@datamti.comwrote in message
news:%2****************@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" <ma******@fitzme.comwrote in message
news:%2****************@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
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" <be****@datamti.comwrote in message
news:OZ**************@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 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" <ne***********@hotmail.comwrote in message
>news:11**********************@b28g2000cwb.goo glegroups.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(?)
>>>
>>
>>
>
>

[BillE]

Perhaps. My assertion, however, is that the documentation should identify
this potential problem in the first place.

"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:ej**************@TK2MSFTNGP05.phx.gbl...

"BillE" <be****@datamti.comwrote in message
news:ui**************@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...

[Marina Levit [MVP]]

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" <be****@datamti.comwrote in message
news:et**************@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 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]" <so*****@nospam.comwrote in message
news:O%***************@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" <be****@datamti.comwrote in message
news:%2****************@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" <ma******@fitzme.comwrote in message
news:%2****************@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
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" <be****@datamti.comwrote in message
news:OZ**************@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 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" <ne***********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.goog legroups.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(?)
>>
>
>

[bruce barker \(sqlwork.com\)]

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" <be****@datamti.comwrote in message
news:OZ**************@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 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" <ne***********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.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(?)

[BillE]

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]" <so*****@nospam.comwrote in message
news:O5**************@TK2MSFTNGP05.phx.gbl...

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" <be****@datamti.comwrote in message
news:et**************@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 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]" <so*****@nospam.comwrote in message
news:O%***************@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" <be****@datamti.comwrote in message
news:%2****************@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" <ma******@fitzme.comwrote in message
news:%2****************@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
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" <be****@datamti.comwrote in message
news:OZ**************@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 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" <ne***********@hotmail.comwrote in message
>news:11**********************@b28g2000cwb.goo glegroups.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(?)
>>>
>>
>>
>
>

[BillE]

Bruce -
You are correct - all the problems you mention are "easy to predict if the
dev takes the time to
lean how a web applications work and its stateless nature".

But knowing "how a web applications work and its stateless nature" does not
predict that the IE action File-New-Window will open a new browser window
which shares the same Session ID as the parent window, and replaces the
content of session variables with damaging consequences.

Thanks for your response, Bruce.
Bill
"bruce barker (sqlwork.com)" <b_*************************@sqlwork.comwrote
in message news:O3**************@TK2MSFTNGP04.phx.gbl...

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" <be****@datamti.comwrote in message
news:OZ**************@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 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" <ne***********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googleg roups.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(?)

[Russell]

Not only is this behavior pretty predictable but it can be quite
useful. I often use session to pass data to a page that I open in a
child window (through JavaScript). It's true that the scenario you
mention is going to be easy to miss in testing... but how often is a
single userr going to log in under one account in one window, begin a
transaction, not complete it, log in as another user in a different
window... you can't expect the documentation to warn you of every
possible pitfall.
BillE wrote:

Bruce -
You are correct - all the problems you mention are "easy to predict if the
dev takes the time to
lean how a web applications work and its stateless nature".

But knowing "how a web applications work and its stateless nature" does not
predict that the IE action File-New-Window will open a new browser window
which shares the same Session ID as the parent window, and replaces the
content of session variables with damaging consequences.

Thanks for your response, Bruce.
Bill
"bruce barker (sqlwork.com)" <b_*************************@sqlwork.comwrote
in message news:O3**************@TK2MSFTNGP04.phx.gbl...

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" <be****@datamti.comwrote in message
news:OZ**************@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 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" <ne***********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.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(?)

[BillE]

Hi Russell -

I'm not sure why this behavior is predicatable. How did you learn of it?

I realized it when I inherited a VB6 web class project, and while
interviewing users for upgrade requirements I was told that sometimes data
entry was save to the wrong entity.

I do understand how it can be useful.

I agree that the documentation should not warn of every possible pitfall.

However, I think there is a responsibility to caution against Probable
pitfalls which can cause major problems.

I think that the usefullness of session variables is very limited because of
this behavior. Since session variables are so convenient, it is very
tempting to use them indiscrimantly if the developer is unaware of this
pitfall.

Thanks!
Bill
"Russell" <ru*****@goisc.comwrote in message
news:11**********************@i42g2000cwa.googlegr oups.com...

Not only is this behavior pretty predictable but it can be quite
useful. I often use session to pass data to a page that I open in a
child window (through JavaScript). It's true that the scenario you
mention is going to be easy to miss in testing... but how often is a
single userr going to log in under one account in one window, begin a
transaction, not complete it, log in as another user in a different
window... you can't expect the documentation to warn you of every
possible pitfall.
BillE wrote:

>Bruce -
You are correct - all the problems you mention are "easy to predict if
the
dev takes the time to
lean how a web applications work and its stateless nature".

But knowing "how a web applications work and its stateless nature" does
not
predict that the IE action File-New-Window will open a new browser window
which shares the same Session ID as the parent window, and replaces the
content of session variables with damaging consequences.

Thanks for your response, Bruce.
Bill
"bruce barker (sqlwork.com)" <b_*************************@sqlwork.com>
wrote
in message news:O3**************@TK2MSFTNGP04.phx.gbl...

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" <be****@datamti.comwrote in message
news:OZ**************@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 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" <ne***********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googleg roups.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(?)

[Damien]

BillE wrote:

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").

You see it as a pitfall - others may see it as a boon. For instance, we
want to provide a link to a dynamically generated booklet for the
client which will open in a new window. In that case, we definitely
*do* want the same session to be shared between the windows, otherwise
we have to go and invent something new for ourselves, or have to expose
potentially sensitive information in e.g. the query string, in order to
find the right data.

Damien

[BillE]

Damien -

I fully agree that this is appropriate behavior in IE. I just think it
should be mentioned somewhere where it will be seen. How did you learn of
this?

My point is that this is such a potentially serious problem, and so likely
to occur, that I don't understand why it is not documented somewhere in MSDN
or the VS documentation. I can only find reference to it in forums where
someone has found out the hard way.

No basic explanation of the use of session variables that I can find
counsels the developer about the risk of a user compromising the application
completely by using Ctrl-N.

Thanks!
Bill

"Damien" <Da*******************@hotmail.comwrote in message
news:11**********************@i42g2000cwa.googlegr oups.com...

BillE wrote:

>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").

You see it as a pitfall - others may see it as a boon. For instance, we
want to provide a link to a dynamically generated booklet for the
client which will open in a new window. In that case, we definitely
*do* want the same session to be shared between the windows, otherwise
we have to go and invent something new for ourselves, or have to expose
potentially sensitive information in e.g. the query string, in order to
find the right data.

Damien