Session Variables

[Brad]

Hi everyone,

I've been using ASP on a few different projects over the past year, either
using Javascript or VBScript. During that time, I've made use of session
variables, but even then, I've tried to keep those variables to a minimum
(which is not always easy).

I've also read on many ASP resource sites (such as fuzzysoftware.com, etc)
that the use of session variables can be a no-no, while others say that it's
perfectly valid to use them extensively. Some articles on these sites state
that if we use session variables on a site that is spanned across a web
farm, those variables will either get corrupt, lost, or even worse, abducted
by UFO's (kidding).

Since I'm sure a lot of you have had more experience in this area than I
have, I was wondering what the "thought of the day" is, pertaining to the
use of session variables.

Thanks guys,
Brad

 

[Dave Anderson]

I avoid them for just about everything. At some point around version 5,
Microsoft tried to give IE the ability to straddle multiple sessions from
within a single Windows user session, and introduced a nightmare that hasn't
resolved itself yet. MS then compounded the problem by taking away from the
user the ability to control whether new windows browse in new sessions.

Look here for a glimpse:
http://aspfaq.com/show.asp?id=2157

I have noticed a sudden increase in lost sessions with IE6 that began a few
months ago, presumably coinciding with the release of some patch. In my
organization, we have documented many machines that behave better or worse
depending on the number of other applications running. Why on earth this
would affect session persistence is beyond me.

Tack on ever-mutating security policies that (a) affect the sharing of
sessions across frames/popups/iframes/new windows, and (b) keep overwriting
preferences every time Windows Update prompts the user to patch the browser
or leave himself vulnerable to an earth-shattering, "new" (MS speak for
"it's been there all along") vulnerability, and it's a wonder that sessions
work at all.

It's a shame, too -- these problems are unique to IE. No other browser gives
session cookies this unique treatment. And even IE behaves properly with
normal cookies (it shares them among all windows). If you design your own
session architecture (generate unique, pseudorandom IDs, send them to the
browser as plain-old cookies, manage session data in a DB, etc.) IE will
work perfectly and in a manner consistent with other browsers. But you can't
use your own cookie to piggyback onto a session, so you can't solve the
problems with session cookies without dropping session variables altogether
(or at least not using them for anything important).

Do I sound bitter? Remediating a bunch of applications written by someone
else will do that to you. Especially when those apps shouldn't be broken,
except for the shifting landscape that is Microsoft Internet Explorer.

I've been using ASP on a few different projects over the past year, either
using Javascript or VBScript. During that time, I've made use of session
variables, but even then, I've tried to keep those variables to a minimum
(which is not always easy).

I've also read on many ASP resource sites (such as fuzzysoftware.com, etc)
that the use of session variables can be a no-no, while others say that it's
perfectly valid to use them extensively. Some articles on these sites state
that if we use session variables on a site that is spanned across a web
farm, those variables will either get corrupt, lost, or even worse, abducted
by UFO's (kidding).

Since I'm sure a lot of you have had more experience in this area than I
have, I was wondering what the "thought of the day" is, pertaining to the
use of session variables.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Brad]

Dave,

Thanks for that FAQ, and thanks also for the insight. It seems that
developing this new [database/user intensive] site is going to be a
nightmare. I'm starting to wonder how so many database/user driven sites are
able to work properly.

*sigh* I'm going to have to try to find some mechanism(s) for this so that I
can *create* a sessionId and store it in a hidden form field, along with
other state variables. The FAQ even states that it's possible for the
normally created sessionId to change from page to page. I'm also going to
have to figure out a mechanism for *properly* storing session data in a
database.

:/

Brad