Some ASP.NET applications use Session Variables extensively to maintain
state.
These should be re-written to use viewstate, hidden fields, querystring,
etc. instead.
This is because if a user opens a new IE window with Ctrl-N or
File-New-Window, BOTH WINDOWS SHARE THE SAME SESSION VARIABLES. This cannot
be prevented.
This means that if you change the value of a session variable in the second
window, it is also changed in the first window.
Session variables should only be used if this behavior is recognized and
compensated for.
I inherited a VB6 web class application which uses session variables
extensively. Users told me that sometimes orders were being added for the
wrong customer. I found that this occured when they opened a second browser
using Ctrl-N, changed the customer in the new window, and then returned to
the first window to add an order. They didn't realize that the customer
displayed in the first window was no longer consistent with the customer ID
stored in the shared CustomerID session variable.
26  3568 
This is a long known issue. If a new browser is pulled from the old browser,
both have the same name, which means they share session. You can prevent
this by checking user input and ensuring you are dealing with the same
record. It is more a practices problem than a session problem.
On the other hand, I agree that you should keep page specific stuff in the
page. ViewState is a good option here.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA http://gregorybeamer.spaces.live.com
*************************************************
Think outside of the box!
*************************************************
"BillE" <be****@datamti.comwrote in message
news:Oo**************@TK2MSFTNGP02.phx.gbl...
Some ASP.NET applications use Session Variables extensively to maintain
state.
These should be re-written to use viewstate, hidden fields, querystring,
etc. instead.
This is because if a user opens a new IE window with Ctrl-N or
File-New-Window, BOTH WINDOWS SHARE THE SAME SESSION VARIABLES. This
cannot be prevented.
This means that if you change the value of a session variable in the
second window, it is also changed in the first window.
Session variables should only be used if this behavior is recognized and
compensated for.
I inherited a VB6 web class application which uses session variables
extensively. Users told me that sometimes orders were being added for the
wrong customer. I found that this occured when they opened a second
browser using Ctrl-N, changed the customer in the new window, and then
returned to the first window to add an order. They didn't realize that
the customer displayed in the first window was no longer consistent with
the customer ID stored in the shared CustomerID session variable.
"Cowboy (Gregory A. Beamer)" <No************@comcast.netNoSpamMwrote in
message news:ei****************@TK2MSFTNGP05.phx.gbl...
On the other hand, I agree that you should keep page specific stuff in the
page. ViewState is a good option here.
That's just common sense, surely...?
I think that the only way to ensure you are dealing with the same record is
to avoid session variables.
For example, if you are using Master pages, as far as I can tell, this means
that a customer ID must be passed by query string for GET requests, and by
hidden fields for POST requests when a new child page is being called.
Is this an accurate statement?
Thanks
-Bill
"Cowboy (Gregory A. Beamer)" <No************@comcast.netNoSpamMwrote in
message news:ei****************@TK2MSFTNGP05.phx.gbl...
This is a long known issue. If a new browser is pulled from the old
browser, both have the same name, which means they share session. You can
prevent this by checking user input and ensuring you are dealing with the
same record. It is more a practices problem than a session problem.
On the other hand, I agree that you should keep page specific stuff in the
page. ViewState is a good option here.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com
*************************************************
Think outside of the box!
*************************************************
"BillE" <be****@datamti.comwrote in message
news:Oo**************@TK2MSFTNGP02.phx.gbl...
>Some ASP.NET applications use Session Variables extensively to maintain
state.
These should be re-written to use viewstate, hidden fields, querystring,
etc. instead.
This is because if a user opens a new IE window with Ctrl-N or
File-New-Window, BOTH WINDOWS SHARE THE SAME SESSION VARIABLES. This
cannot be prevented.
This means that if you change the value of a session variable in the
second window, it is also changed in the first window.
Session variables should only be used if this behavior is recognized and
compensated for.
I inherited a VB6 web class application which uses session variables
extensively. Users told me that sometimes orders were being added for
the wrong customer. I found that this occured when they opened a second
browser using Ctrl-N, changed the customer in the new window, and then
returned to the first window to add an order. They didn't realize that
the customer displayed in the first window was no longer consistent with
the customer ID stored in the shared CustomerID session variable.
"BillE" <be****@datamti.comwrote in message
news:%2******************@TK2MSFTNGP03.phx.gbl...
For example, if you are using Master pages, as far as I can tell, this
means that a customer ID must be passed by query string for GET requests,
and by hidden fields for POST requests when a new child page is being
called.
Is this an accurate statement?
Not im my experience - I use ViewState all the time within ContentPages...
Do your content pages initially receive parameters from query strings or
hidden fields?
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:er**************@TK2MSFTNGP04.phx.gbl...
"BillE" <be****@datamti.comwrote in message
news:%2******************@TK2MSFTNGP03.phx.gbl...
>For example, if you are using Master pages, as far as I can tell, this
means that a customer ID must be passed by query string for GET requests,
and by hidden fields for POST requests when a new child page is being
called.
Is this an accurate statement?
Not im my experience - I use ViewState all the time within ContentPages...
"BillE" <be****@datamti.comwrote in message
news:ul**************@TK2MSFTNGP04.phx.gbl...
Do your content pages initially receive parameters from query strings or
hidden fields?
Neither - they most often receive them from a Session variable which is read
and destroyed on Page_Load, surrounded by if (!IsPostBack). If the user
tries to open the page directly either by typing the URL into the address
bar directly or clicking File, New, that Session variable won't be there, so
the process will not continue. Instead, the user will be redirected to an
error page telling them not to do what they tried to do...
Good solution. Thanks!
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:e2*************@TK2MSFTNGP05.phx.gbl...
"BillE" <be****@datamti.comwrote in message
news:ul**************@TK2MSFTNGP04.phx.gbl...
>Do your content pages initially receive parameters from query strings or
hidden fields?
Neither - they most often receive them from a Session variable which is
read and destroyed on Page_Load, surrounded by if (!IsPostBack). If the
user tries to open the page directly either by typing the URL into the
address bar directly or clicking File, New, that Session variable won't be
there, so the process will not continue. Instead, the user will be
redirected to an error page telling them not to do what they tried to
do...
Your concern is valid, but this isn't really a problem with session
variables. It's more a question of where you should store different kind
of state.
Session variables are suitable for values that remain the same
throughout the session, like the id of the logged in user. The id of the
customer that you are currently viewing is something that should follow
the page rather than the session.
If you would store session specific data in an application variable,
that would of course be a problem if there ever is more than one session
active at the same time. In the same way, if you store page specific
data in a session variable, there is a problem if one user has more than
one page open at the same time.
BillE wrote:
Some ASP.NET applications use Session Variables extensively to maintain
state.
These should be re-written to use viewstate, hidden fields, querystring,
etc. instead.
This is because if a user opens a new IE window with Ctrl-N or
File-New-Window, BOTH WINDOWS SHARE THE SAME SESSION VARIABLES. This cannot
be prevented.
This means that if you change the value of a session variable in the second
window, it is also changed in the first window.
Session variables should only be used if this behavior is recognized and
compensated for.
I inherited a VB6 web class application which uses session variables
extensively. Users told me that sometimes orders were being added for the
wrong customer. I found that this occured when they opened a second browser
using Ctrl-N, changed the customer in the new window, and then returned to
the first window to add an order. They didn't realize that the customer
displayed in the first window was no longer consistent with the customer ID
stored in the shared CustomerID session variable.
Well put.
Unfortunately, I suspect there are many developers who use the convenience
of session variables to persist values (like Customer ID) without realizing
that a user will eventually compromise the application with a simple action
like Ctrl-N.
The only time I see this risk mentioned is in posts in newsgroups and forums
from distressed and perplexed developers!
Thanks
Bill
"Göran Andersson" <gu***@guffa.comwrote in message
news:Of****************@TK2MSFTNGP03.phx.gbl...
Your concern is valid, but this isn't really a problem with session
variables. It's more a question of where you should store different kind
of state.
Session variables are suitable for values that remain the same throughout
the session, like the id of the logged in user. The id of the customer
that you are currently viewing is something that should follow the page
rather than the session.
If you would store session specific data in an application variable, that
would of course be a problem if there ever is more than one session active
at the same time. In the same way, if you store page specific data in a
session variable, there is a problem if one user has more than one page
open at the same time.
BillE wrote:
>Some ASP.NET applications use Session Variables extensively to maintain
state.
These should be re-written to use viewstate, hidden fields, querystring,
etc. instead.
This is because if a user opens a new IE window with Ctrl-N or
File-New-Window, BOTH WINDOWS SHARE THE SAME SESSION VARIABLES. This
cannot be prevented.
This means that if you change the value of a session variable in the
second window, it is also changed in the first window.
Session variables should only be used if this behavior is recognized and
compensated for.
I inherited a VB6 web class application which uses session variables
extensively. Users told me that sometimes orders were being added for
the wrong customer. I found that this occured when they opened a second
browser using Ctrl-N, changed the customer in the new window, and then
returned to the first window to add an order. They didn't realize that
the customer displayed in the first window was no longer consistent with
the customer ID stored in the shared CustomerID session variable.
Just because session variables are bad to use in certain situations does not
mean that they are always bad. Just like virtually every development
technique, there are trade offs that should be carefully weighed before
deciding the course on which to embark.
When I first saw the title of your post I thought you were going to rave
about what a problem session variables can be when it comes to scalability,
but you didn't even mention that.
Despite such issues, its hard to deny what a convenient development time
saver session variables can be.
--
I hope this helps,
Steve C. Orr
MCSD, MVP, CSM http://SteveOrr.net
"BillE" <be****@datamti.comwrote in message
news:Oo**************@TK2MSFTNGP02.phx.gbl...
Some ASP.NET applications use Session Variables extensively to maintain
state.
These should be re-written to use viewstate, hidden fields, querystring,
etc. instead.
This is because if a user opens a new IE window with Ctrl-N or
File-New-Window, BOTH WINDOWS SHARE THE SAME SESSION VARIABLES. This
cannot be prevented.
This means that if you change the value of a session variable in the
second window, it is also changed in the first window.
Session variables should only be used if this behavior is recognized and
compensated for.
I inherited a VB6 web class application which uses session variables
extensively. Users told me that sometimes orders were being added for the
wrong customer. I found that this occured when they opened a second
browser using Ctrl-N, changed the customer in the new window, and then
returned to the first window to add an order. They didn't realize that
the customer displayed in the first window was no longer consistent with
the customer ID stored in the shared CustomerID session variable.
Unfortunately, I suspect there are many developers who use the convenience
of session variables to persist values (like Customer ID) without
realizing that a user will eventually compromise the application with a
simple action like Ctrl-N.
I can really hear from this sentence that you really expected a(ny) session
to be unique.
In fact from beginning NO browser window is unique, that's http/tcp, no
window is unique.
You can only mess with html to try it to make unique.
But you should always bear in mind that one can have multiple windows open
and that you'll (possibly) not be able to distinguish them.. ever..
Messing wiht hidden controls/viewstate.. o well it's static but an unique
value injected..?
Saving the html and open it again also loads any previous ID you managed, so
that fails as well.
"BillE" <be****@datamti.comschreef in bericht
news:%2****************@TK2MSFTNGP05.phx.gbl...
Well put.
Unfortunately, I suspect there are many developers who use the convenience
of session variables to persist values (like Customer ID) without
realizing that a user will eventually compromise the application with a
simple action like Ctrl-N.
The only time I see this risk mentioned is in posts in newsgroups and
forums from distressed and perplexed developers!
Thanks
Bill
"Göran Andersson" <gu***@guffa.comwrote in message
news:Of****************@TK2MSFTNGP03.phx.gbl...
>Your concern is valid, but this isn't really a problem with session
variables. It's more a question of where you should store different kind
of state.
Session variables are suitable for values that remain the same throughout
the session, like the id of the logged in user. The id of the customer
that you are currently viewing is something that should follow the page
rather than the session.
If you would store session specific data in an application variable, that
would of course be a problem if there ever is more than one session
active at the same time. In the same way, if you store page specific data
in a session variable, there is a problem if one user has more than one
page open at the same time.
BillE wrote:
>>Some ASP.NET applications use Session Variables extensively to maintain
state.
These should be re-written to use viewstate, hidden fields, querystring,
etc. instead.
This is because if a user opens a new IE window with Ctrl-N or
File-New-Window, BOTH WINDOWS SHARE THE SAME SESSION VARIABLES. This
cannot be prevented.
This means that if you change the value of a session variable in the
second window, it is also changed in the first window.
Session variables should only be used if this behavior is recognized and
compensated for.
I inherited a VB6 web class application which uses session variables
extensively. Users told me that sometimes orders were being added for
the wrong customer. I found that this occured when they opened a second
browser using Ctrl-N, changed the customer in the new window, and then
returned to the first window to add an order. They didn't realize that
the customer displayed in the first window was no longer consistent with
the customer ID stored in the shared CustomerID session variable.
On Thu, 19 Oct 2006 17:01:21 +0100, "Mark Rae"
<ma**@markNOSPAMrae.comwrote:
>"BillE" <be****@datamti.comwrote in message
news:ul**************@TK2MSFTNGP04.phx.gbl...
>Do your content pages initially receive parameters from query strings or
hidden fields?
Neither - they most often receive them from a Session variable which is read
and destroyed on Page_Load, surrounded by if (!IsPostBack). If the user
tries to open the page directly either by typing the URL into the address
bar directly or clicking File, New, that Session variable won't be there, so
the process will not continue. Instead, the user will be redirected to an
error page telling them not to do what they tried to do...
I'm still waiting for the Microsoft Electroshock Feedback Keyboard.
On Thu, 19 Oct 2006 15:49:08 -0700, "Steve C. Orr [MVP, MCSD]"
<St***@Orr.netwrote:
>Just because session variables are bad to use in certain situations does not
mean that they are always bad. Just like virtually every development
technique, there are trade offs that should be carefully weighed before
deciding the course on which to embark.
When I first saw the title of your post I thought you were going to rave
about what a problem session variables can be when it comes to scalability,
but you didn't even mention that.
Despite such issues, its hard to deny what a convenient development time
saver session variables can be.
I'm new to ASP.NET development so I appreciate the whole thread, and
the one it descended from. I didn't realize that folks open up new
browser windows that share the session state so I will code for that.
How does IE7's tabbed windows (and Firefox) work - do those share the
session or start a new one?
dgk-
You are the intended audience for my post.
Thanks
Bill
"dgk" <dg*@somewhere.comwrote in message
news:6l********************************@4ax.com...
On Thu, 19 Oct 2006 15:49:08 -0700, "Steve C. Orr [MVP, MCSD]"
<St***@Orr.netwrote:
>>Just because session variables are bad to use in certain situations does
not
mean that they are always bad. Just like virtually every development
technique, there are trade offs that should be carefully weighed before
deciding the course on which to embark.
When I first saw the title of your post I thought you were going to rave
about what a problem session variables can be when it comes to
scalability,
but you didn't even mention that.
Despite such issues, its hard to deny what a convenient development time
saver session variables can be.
I'm new to ASP.NET development so I appreciate the whole thread, and
the one it descended from. I didn't realize that folks open up new
browser windows that share the session state so I will code for that.
How does IE7's tabbed windows (and Firefox) work - do those share the
session or start a new one?
The VS 2005 documentation clearly warns about performance issues in ASP.NET
State Management Recommendations (Disadvantage of Using Session State), so I
don't need to rave about it.
I agree with you on every point - I just want novice developers to know
about the trade-offs! How are they to know? This behavior is not mentioned
in any documentation I can find.
Thanks!
Bill
"Steve C. Orr [MVP, MCSD]" <St***@Orr.netwrote in message
news:uV**************@TK2MSFTNGP05.phx.gbl...
Just because session variables are bad to use in certain situations does
not mean that they are always bad. Just like virtually every development
technique, there are trade offs that should be carefully weighed before
deciding the course on which to embark.
When I first saw the title of your post I thought you were going to rave
about what a problem session variables can be when it comes to
scalability, but you didn't even mention that.
Despite such issues, its hard to deny what a convenient development time
saver session variables can be.
--
I hope this helps,
Steve C. Orr
MCSD, MVP, CSM
http://SteveOrr.net
"BillE" <be****@datamti.comwrote in message
news:Oo**************@TK2MSFTNGP02.phx.gbl...
>Some ASP.NET applications use Session Variables extensively to maintain
state.
These should be re-written to use viewstate, hidden fields, querystring,
etc. instead.
This is because if a user opens a new IE window with Ctrl-N or
File-New-Window, BOTH WINDOWS SHARE THE SAME SESSION VARIABLES. This
cannot be prevented.
This means that if you change the value of a session variable in the
second window, it is also changed in the first window.
Session variables should only be used if this behavior is recognized and
compensated for.
I inherited a VB6 web class application which uses session variables
extensively. Users told me that sometimes orders were being added for
the wrong customer. I found that this occured when they opened a second
browser using Ctrl-N, changed the customer in the new window, and then
returned to the first window to add an order. They didn't realize that
the customer displayed in the first window was no longer consistent with
the customer ID stored in the shared CustomerID session variable.
Hi Edwin -
I will reiterate that I have no objection to any behavior of ASP, IE, or
Session State.
My point is to alert developers to this potential pitfall. This will
inevitably occur if session variables are not used very carefully. When it
occurs, it will go possibly go undetected until significant damage has been
done.
Thanks
-Bill
"Edwin Knoppert" <ne**@hellobasic.comwrote in message
news:45**********************@text.nova.planet.nl. ..
>Unfortunately, I suspect there are many developers who use the
convenience of session variables to persist values (like Customer ID)
without realizing that a user will eventually compromise the application
with a simple action like Ctrl-N.
I can really hear from this sentence that you really expected a(ny)
session to be unique.
In fact from beginning NO browser window is unique, that's http/tcp, no
window is unique.
You can only mess with html to try it to make unique.
But you should always bear in mind that one can have multiple windows open
and that you'll (possibly) not be able to distinguish them.. ever..
Messing wiht hidden controls/viewstate.. o well it's static but an unique
value injected..?
Saving the html and open it again also loads any previous ID you managed,
so that fails as well.
"BillE" <be****@datamti.comschreef in bericht
news:%2****************@TK2MSFTNGP05.phx.gbl...
>Well put.
Unfortunately, I suspect there are many developers who use the
convenience of session variables to persist values (like Customer ID)
without realizing that a user will eventually compromise the application
with a simple action like Ctrl-N.
The only time I see this risk mentioned is in posts in newsgroups and
forums from distressed and perplexed developers!
Thanks
Bill
"Göran Andersson" <gu***@guffa.comwrote in message
news:Of****************@TK2MSFTNGP03.phx.gbl...
>>Your concern is valid, but this isn't really a problem with session
variables. It's more a question of where you should store different kind
of state.
Session variables are suitable for values that remain the same
throughout the session, like the id of the logged in user. The id of the
customer that you are currently viewing is something that should follow
the page rather than the session.
If you would store session specific data in an application variable,
that would of course be a problem if there ever is more than one session
active at the same time. In the same way, if you store page specific
data in a session variable, there is a problem if one user has more than
one page open at the same time.
BillE wrote:
Some ASP.NET applications use Session Variables extensively to maintain
state.
These should be re-written to use viewstate, hidden fields,
querystring, etc. instead.
This is because if a user opens a new IE window with Ctrl-N or
File-New-Window, BOTH WINDOWS SHARE THE SAME SESSION VARIABLES. This
cannot be prevented.
This means that if you change the value of a session variable in the
second window, it is also changed in the first window.
Session variables should only be used if this behavior is recognized
and compensated for.
I inherited a VB6 web class application which uses session variables
extensively. Users told me that sometimes orders were being added for
the wrong customer. I found that this occured when they opened a
second browser using Ctrl-N, changed the customer in the new window,
and then returned to the first window to add an order. They didn't
realize that the customer displayed in the first window was no longer
consistent with the customer ID stored in the shared CustomerID session
variable.
I believe the same behavior will occur in IE7 tabbed windows and in Firefox.
-Bill
"dgk" <dg*@somewhere.comwrote in message
news:6l********************************@4ax.com...
On Thu, 19 Oct 2006 15:49:08 -0700, "Steve C. Orr [MVP, MCSD]"
<St***@Orr.netwrote:
>>Just because session variables are bad to use in certain situations does
not
mean that they are always bad. Just like virtually every development
technique, there are trade offs that should be carefully weighed before
deciding the course on which to embark.
When I first saw the title of your post I thought you were going to rave
about what a problem session variables can be when it comes to
scalability,
but you didn't even mention that.
Despite such issues, its hard to deny what a convenient development time
saver session variables can be.
I'm new to ASP.NET development so I appreciate the whole thread, and
the one it descended from. I didn't realize that folks open up new
browser windows that share the session state so I will code for that.
How does IE7's tabbed windows (and Firefox) work - do those share the
session or start a new one?
On Thu, 19 Oct 2006 10:15:00 -0400, "BillE" <be****@datamti.com>
wrote:
>Some ASP.NET applications use Session Variables extensively to maintain
state.
These should be re-written to use viewstate, hidden fields, querystring,
etc. instead.
OK....
>This is because if a user opens a new IE window with Ctrl-N or
File-New-Window, BOTH WINDOWS SHARE THE SAME SESSION VARIABLES. This cannot
be prevented.
Yep...
>This means that if you change the value of a session variable in the second
window, it is also changed in the first window.
Session variables should only be used if this behavior is recognized and
compensated for.
There are many different things can replace 'session variables' in the
sentence above.
>I inherited a VB6 web class application which uses session variables
extensively. Users told me that sometimes orders were being added for the
wrong customer. I found that this occured when they opened a second browser
using Ctrl-N, changed the customer in the new window, and then returned to
the first window to add an order. They didn't realize that the customer
displayed in the first window was no longer consistent with the customer ID
stored in the shared CustomerID session variable.
Walk through the way you and the user think it should work and try to
figure how the road should fork when a second, third, fourth, ...
browser is opened. How does the server reconcile the existence of the
new client? How are authentication tickets to be handled? Is the new
client data co-joined to the original client's data or is a completely
different entity considered? When a user logs out does the logout
encompass all open browsers or just the one instance? Keep asking
questions and the additional complexity starts to resemble Hydra.
That the user "didn't realize" how things work suggests training
issues. It always helps to know how computers work. There may be
design and implementation issues as well.
regards
A.G.
The primary issue was that the developer didn't know that Ctrl-N opened a
new window which shared the same session variables as the parent window, and
didn't code to allow for this.
"Registered User" <n4***@ix.netcom.comwrote in message
news:pv********************************@4ax.com...
On Thu, 19 Oct 2006 10:15:00 -0400, "BillE" <be****@datamti.com>
wrote:
>>Some ASP.NET applications use Session Variables extensively to maintain
state.
These should be re-written to use viewstate, hidden fields, querystring,
etc. instead.
OK....
>>This is because if a user opens a new IE window with Ctrl-N or
File-New-Window, BOTH WINDOWS SHARE THE SAME SESSION VARIABLES. This
cannot
be prevented.
Yep...
>>This means that if you change the value of a session variable in the
second
window, it is also changed in the first window.
Session variables should only be used if this behavior is recognized and
compensated for.
There are many different things can replace 'session variables' in the
sentence above.
>>I inherited a VB6 web class application which uses session variables
extensively. Users told me that sometimes orders were being added for the
wrong customer. I found that this occured when they opened a second
browser
using Ctrl-N, changed the customer in the new window, and then returned to
the first window to add an order. They didn't realize that the customer
displayed in the first window was no longer consistent with the customer
ID
stored in the shared CustomerID session variable.
Walk through the way you and the user think it should work and try to
figure how the road should fork when a second, third, fourth, ...
browser is opened. How does the server reconcile the existence of the
new client? How are authentication tickets to be handled? Is the new
client data co-joined to the original client's data or is a completely
different entity considered? When a user logs out does the logout
encompass all open browsers or just the one instance? Keep asking
questions and the additional complexity starts to resemble Hydra.
That the user "didn't realize" how things work suggests training
issues. It always helps to know how computers work. There may be
design and implementation issues as well.
regards
A.G.
I agree with you on every point - I just want novice developers to know
about the trade-offs! How are they to know? This behavior is not
mentioned in any documentation I can find.
I admire your desire to see the community benefit from an understanding of
issues that may cause a web application to misbehave, or cause a security
risk. However, it is important to understand a couple of things about this:
1. A web application is, by nature, a complex and tricky application to
develop, and this is not due to .Net technology, but due to a number of
environmental factors that have existed on the WWW since long before there
*was* a .Net platform. These include the HTTP protocol, its stateless
nature, a lack of standards in user agent technology which resulted in a
large variety of user agents that behave differently in different ways, a
lack of an HTML standard, various versions of HTML, a poorly-architected
HTML standard, and a variety of extensions for HTML, such as JavaScript
(various versions) and CSS (various versions), which were also adopted in
different ways by browser and user agent vendors. Thankfully, standards are
emerging and improving rapidly, but legacy software and technology will
remain for years to come.
2. How Session cookies are handled by different user agents is only one of
many issues that a developer will encounter in web application development,
due to the issues mentioned in point 1. Dealing with the vagaries of
different user agents, how these user agents are custom-configured by the
users, different flavors of HTML, the stateless nature of HTTP, resultant
security issues, and network issues, such as dropped packets, are all issues
that contribute to the difficulty in writing solid web applications. In
other words, Session State is a very small part of the problem.
3. It is not the responsibility of Microsoft to document all of these
pre-existing non-Microsoft technologies, the various browser types (other
than Internet Explorer), web servers, and so on. It is the responsibility of
the developer to learn and understand them. Yes, this is a gargantuan task,
but if one wants to play the game, one has 2 choices: learn the game, or
lose the game.
--
HTH,
Kevin Spencer
Microsoft MVP
Short Order Coder http://unclechutney.blogspot.com
What You Seek Is What You Get
"BillE" <be****@datamti.comwrote in message
news:O1**************@TK2MSFTNGP03.phx.gbl...
The VS 2005 documentation clearly warns about performance issues in
ASP.NET State Management Recommendations (Disadvantage of Using Session
State), so I don't need to rave about it.
I agree with you on every point - I just want novice developers to know
about the trade-offs! How are they to know? This behavior is not
mentioned in any documentation I can find.
Thanks!
Bill
"Steve C. Orr [MVP, MCSD]" <St***@Orr.netwrote in message
news:uV**************@TK2MSFTNGP05.phx.gbl...
>Just because session variables are bad to use in certain situations does
not mean that they are always bad. Just like virtually every development
technique, there are trade offs that should be carefully weighed before
deciding the course on which to embark.
When I first saw the title of your post I thought you were going to rave
about what a problem session variables can be when it comes to
scalability, but you didn't even mention that.
Despite such issues, its hard to deny what a convenient development time
saver session variables can be.
--
I hope this helps,
Steve C. Orr
MCSD, MVP, CSM
http://SteveOrr.net
"BillE" <be****@datamti.comwrote in message
news:Oo**************@TK2MSFTNGP02.phx.gbl...
>>Some ASP.NET applications use Session Variables extensively to maintain
state.
These should be re-written to use viewstate, hidden fields, querystring,
etc. instead.
This is because if a user opens a new IE window with Ctrl-N or
File-New-Window, BOTH WINDOWS SHARE THE SAME SESSION VARIABLES. This
cannot be prevented.
This means that if you change the value of a session variable in the
second window, it is also changed in the first window.
Session variables should only be used if this behavior is recognized and
compensated for.
I inherited a VB6 web class application which uses session variables
extensively. Users told me that sometimes orders were being added for
the wrong customer. I found that this occured when they opened a second
browser using Ctrl-N, changed the customer in the new window, and then
returned to the first window to add an order. They didn't realize that
the customer displayed in the first window was no longer consistent with
the customer ID stored in the shared CustomerID session variable.
Between them, I think the VS documentation and MSDN do an admirable job of
addressing most, if not all, of the points you mention! Certainly HTML
issues are described fully. CSS, JavaScript, security issues, network
issues are all described.
Better documentation of this behavior of IE with respect to session
variables should also be included.
Thanks
Bill
"Kevin Spencer" <sp**@uce.govwrote in message
news:uK**************@TK2MSFTNGP03.phx.gbl...
>I agree with you on every point - I just want novice developers to know
about the trade-offs! How are they to know? This behavior is not
mentioned in any documentation I can find.
I admire your desire to see the community benefit from an understanding of
issues that may cause a web application to misbehave, or cause a security
risk. However, it is important to understand a couple of things about
this:
1. A web application is, by nature, a complex and tricky application to
develop, and this is not due to .Net technology, but due to a number of
environmental factors that have existed on the WWW since long before there
*was* a .Net platform. These include the HTTP protocol, its stateless
nature, a lack of standards in user agent technology which resulted in a
large variety of user agents that behave differently in different ways, a
lack of an HTML standard, various versions of HTML, a poorly-architected
HTML standard, and a variety of extensions for HTML, such as JavaScript
(various versions) and CSS (various versions), which were also adopted in
different ways by browser and user agent vendors. Thankfully, standards
are emerging and improving rapidly, but legacy software and technology
will remain for years to come.
2. How Session cookies are handled by different user agents is only one of
many issues that a developer will encounter in web application
development, due to the issues mentioned in point 1. Dealing with the
vagaries of different user agents, how these user agents are
custom-configured by the users, different flavors of HTML, the stateless
nature of HTTP, resultant security issues, and network issues, such as
dropped packets, are all issues that contribute to the difficulty in
writing solid web applications. In other words, Session State is a very
small part of the problem.
3. It is not the responsibility of Microsoft to document all of these
pre-existing non-Microsoft technologies, the various browser types (other
than Internet Explorer), web servers, and so on. It is the responsibility
of the developer to learn and understand them. Yes, this is a gargantuan
task, but if one wants to play the game, one has 2 choices: learn the
game, or lose the game.
--
HTH,
Kevin Spencer
Microsoft MVP
Short Order Coder
http://unclechutney.blogspot.com
What You Seek Is What You Get
"BillE" <be****@datamti.comwrote in message
news:O1**************@TK2MSFTNGP03.phx.gbl...
>The VS 2005 documentation clearly warns about performance issues in
ASP.NET State Management Recommendations (Disadvantage of Using Session
State), so I don't need to rave about it.
I agree with you on every point - I just want novice developers to know
about the trade-offs! How are they to know? This behavior is not
mentioned in any documentation I can find.
Thanks!
Bill
"Steve C. Orr [MVP, MCSD]" <St***@Orr.netwrote in message
news:uV**************@TK2MSFTNGP05.phx.gbl...
>>Just because session variables are bad to use in certain situations does
not mean that they are always bad. Just like virtually every
development technique, there are trade offs that should be carefully
weighed before deciding the course on which to embark.
When I first saw the title of your post I thought you were going to rave
about what a problem session variables can be when it comes to
scalability, but you didn't even mention that.
Despite such issues, its hard to deny what a convenient development time
saver session variables can be.
--
I hope this helps,
Steve C. Orr
MCSD, MVP, CSM
http://SteveOrr.net
"BillE" <be****@datamti.comwrote in message
news:Oo**************@TK2MSFTNGP02.phx.gbl...
Some ASP.NET applications use Session Variables extensively to maintain
state.
These should be re-written to use viewstate, hidden fields,
querystring, etc. instead.
This is because if a user opens a new IE window with Ctrl-N or
File-New-Window, BOTH WINDOWS SHARE THE SAME SESSION VARIABLES. This
cannot be prevented.
This means that if you change the value of a session variable in the
second window, it is also changed in the first window.
Session variables should only be used if this behavior is recognized
and compensated for.
I inherited a VB6 web class application which uses session variables
extensively. Users told me that sometimes orders were being added for
the wrong customer. I found that this occured when they opened a
second browser using Ctrl-N, changed the customer in the new window,
and then returned to the first window to add an order. They didn't
realize that the customer displayed in the first window was no longer
consistent with the customer ID stored in the shared CustomerID session
variable.
Hi,
BillE wrote:
The primary issue was that the developer didn't know that Ctrl-N opened a
new window which shared the same session variables as the parent window, and
didn't code to allow for this.
I am really surprised that a developer didn't know that. It's a common
behaviour. After all, all browsers react the same, if you press Ctrl-N
in Firefox, you also get a new window in the same session.
IE is special only because it allows starting more than one process,
each of them with a different session ID (if you select the Internet
Explorer icon twice in the Start menu, for example, you start two
instances of IEXPLORE.EXE, which can easily be seen in the task
manager). Firefox doesn't react the same: It allows only one instance of
the process. So actually, the thing you should warn against is not that
two IE windows share the same session ID, but rather that in some cases,
they don't ;-)
I want to add that I recommend using the ViewState with a lot of care,
because if you don't use it carefully, you send a lot of unuseful
information back and forth on every postback. We had cases where an
uncarefully used ViewState was many KB long, which was unbearable for
our users with a modem connection. Disabling the ViewState on a control
should IMHO be the very first thing a developer does when he adds the
control to the page, and then the ViewState should be enabled on demand
only.
Every technology has drawbacks.
Greetings,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch
Bonjour, Laurent
I think you would be surprised at the number of developers who don't know
that.
Google on "asp.net session variables ctrl+N". Lots of panicky posts and
helpful responses (and some smug responses too).
If you didn't know you needed to manage 'ctrl+N', how would you find out?
-Bill
"Laurent Bugnion" <ga*********@bluewin.chwrote in message
news:eX**************@TK2MSFTNGP03.phx.gbl...
Hi,
BillE wrote:
>The primary issue was that the developer didn't know that Ctrl-N opened a
new window which shared the same session variables as the parent window,
and didn't code to allow for this.
I am really surprised that a developer didn't know that. It's a common
behaviour. After all, all browsers react the same, if you press Ctrl-N in
Firefox, you also get a new window in the same session.
IE is special only because it allows starting more than one process, each
of them with a different session ID (if you select the Internet Explorer
icon twice in the Start menu, for example, you start two instances of
IEXPLORE.EXE, which can easily be seen in the task manager). Firefox
doesn't react the same: It allows only one instance of the process. So
actually, the thing you should warn against is not that two IE windows
share the same session ID, but rather that in some cases, they don't ;-)
I want to add that I recommend using the ViewState with a lot of care,
because if you don't use it carefully, you send a lot of unuseful
information back and forth on every postback. We had cases where an
uncarefully used ViewState was many KB long, which was unbearable for our
users with a modem connection. Disabling the ViewState on a control should
IMHO be the very first thing a developer does when he adds the control to
the page, and then the ViewState should be enabled on demand only.
Every technology has drawbacks.
Greetings,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch
dgk wrote:
On Thu, 19 Oct 2006 15:49:08 -0700, "Steve C. Orr [MVP, MCSD]"
<St***@Orr.netwrote:
>Just because session variables are bad to use in certain situations does not
mean that they are always bad. Just like virtually every development
technique, there are trade offs that should be carefully weighed before
deciding the course on which to embark.
When I first saw the title of your post I thought you were going to rave
about what a problem session variables can be when it comes to scalability,
but you didn't even mention that.
Despite such issues, its hard to deny what a convenient development time
saver session variables can be.
I'm new to ASP.NET development so I appreciate the whole thread, and
the one it descended from. I didn't realize that folks open up new
browser windows that share the session state so I will code for that.
How does IE7's tabbed windows (and Firefox) work - do those share the
session or start a new one?
Tabbed windows are always windows in the same instance of the browser,
so they will always share the same session.
The only time the windows doesn't share the same session is if they are
in separate instances of the browser, i.e. when you start a new browser
from the start menu (or similar).
Firefox only has one instance open ever. If you try to start a new
instance, a new window in the current instance is created instead, so
all windows in firefox share the same session.
On Sat, 21 Oct 2006 05:25:58 +0200, Göran Andersson <gu***@guffa.com>
wrote:
>
Firefox only has one instance open ever. If you try to start a new
instance, a new window in the current instance is created instead, so
all windows in firefox share the same session.
That seems like a real weakness to me. I would like the option (now
that I know it exists, that is).
It's not too hard to manage this, though (although not as easy as just
populating the session variables and leaving them).
I use the solution Mark Rae mentioned -- populate the session variable when
a page is being opened, and then retrieve the session variable, stash the
value in viewstate or a hidden field, and destroy the session variable.
This also prevents inconsistent data from users using the back button.
"dgk" <dg*@somewhere.comwrote in message
news:ij********************************@4ax.com...
On Sat, 21 Oct 2006 05:25:58 +0200, Göran Andersson <gu***@guffa.com>
wrote:
>>
Firefox only has one instance open ever. If you try to start a new
instance, a new window in the current instance is created instead, so
all windows in firefox share the same session.
That seems like a real weakness to me. I would like the option (now
that I know it exists, that is).
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Jake Lloyd |
last post by:
In "A Note on Security In PHP" (partly in reference to a security flaw
that exists or recently did exist in phpBB) at
http://nl3.php.net/security-note.php
The PHP Group makes this claim:
"Every...
|
by: patel |
last post by:
Hello,
I get this warning with my PHP code sometimes. It will come up, and
then after reloading the page once or twice, it will go away. Any
ideas? The code is below:
Warning: Unknown: Your...
|
by: tshad |
last post by:
I have been using the default session state (InProc) and have found that I
have been loosing my information after a period of time (normally 20
minutes).
Is there anyway to find out how much...
|
by: lawrence k |
last post by:
How can I find out where my script is outputting to the screen for the
first time?
My error logs are full of stuff like this:
PHP Warning: session_start(): Cannot send
session cache...
|
by: Atul Shukla |
last post by:
Hi,
How can I avoid application timeout? Generally a web application time out is
20 minutes, however, we can define this timeout in web.config to any number
of minutes. After giving 500 minutes of...
|
by: mcserret |
last post by:
I know this is a recurring problem that has been addressed here
before, but even after reading all that has gone before, I am still
stumped.
I have a form that is designed to send data to a PHP...
|
by: Jeff |
last post by:
I turned on errors in php:
ini_set('display_errors','1');
And I got a slew of notices and a couple of warnings.
The notices are mostly missing indexes from doing things like this:
...
|
by: anithaapr05 |
last post by:
I have got the warning in event viewer when i wrote the code in global.asax session_end().
When the user sessions time out, the Session_End event fires successfully.But i got the waring in event...
|
by: anithaapr05 |
last post by:
After the session end i try to write the session value.In this, it write the session value after the session end, but i got the warning in application event.
My asp code:
void...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
