Warning - AVOID SESSION VARIABLES

[Kevin Spencer]

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]

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

 

[Laurent Bugnion]

Hi,

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

 

[BillE]

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

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

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.

 

[dgk]

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

 

[BillE]

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.