Library tutorials & articles
When Session Variables Go Bad
I am the owner of a small application development consulting company that specialized in the design and implementation of Internet-based applications. While there are others who can make a web sit...
- Introduction
- The Implementation Details
- Tying Up Loose Ends
- Cap'n. The Resources. They Canna Take It!
- Down on the Web Farm
- Summary
The Implementation Details
The ability to even have Session variables is premised on IIS being allowed to place a cookie onto the client's system. This cookie contains a 16-character identifier that allows IIS to track the requests that are made by that client. Internally, this identifier is associated with a collection. This association allows IIS to not only implement Session variables, but also to time out the session itself (and the variables along with it).
The fact that the identifier is a cookie means that those users (and you know who you are) who don't have cookies turned on will not have their session variables stored. Just so that we're clear, not accepting cookies doesnot mean that the session variables won't exist. But every time the cookie-less user makes a page request, a new session id will be generated, along with a call to the Session_OnStart procedure. So there is, in effect, no persistence of the variables from page to page. What's worse, you're site will bombard them with requests to store a cookie on their system (one for every page that they hit). So, in the interest of a better user interface, a different approach might be called for.
The 'better' way would be to check to see if the user will even accept cookies before going too far into your web site. The technique to do this is quite simple. On one page, set a cookie on the user's browser. Then on a subsequent page, check for the presence of that cookie. If it's not there, then the user has disabled cookies, at which point you may want to warn them what they're in for.
As we've already mentioned Session variables are implemented as a collection
of values. As such, there is no practical limit to the number or type of variables
that can be stored. There are, however, technical reasons to limit the objects
that are stored. But more on that in the next section.
Related articles
Related discussion
-
Header and Footer in Web page print
by fhajaj (4 replies)
-
help me to get simple requirement
by Slicksim (1 replies)
-
Gridview -> Template Field -> Button
by antti.simonen (1 replies)
-
Classic ASP : Page expires
by chezhian_in05 (0 replies)
-
ASP VS PHP
by paulfp (9 replies)
Related podcasts
-
ASP.NET Caching and Performance
Steve Smith, owner of ASP Alliance and Lake Quincy Media joins us today to teach us about some hidden gems in ASP.NET caching and performance. Steve’s expertise in this area comes from first-hand experience as Lake Quincy’s ad system serves over 60 requests per second and handles over 150 million...
Related jobs
-
Microsoft .Net Architect
in AMSTERDAM (€50K-€90K per annum) -
Microsoft Dynamics CRM Technical Consultant
in Netherlands (€50K-€90K per annum) -
Technical Support Engineer EMEA
in Reading (£50K-£50K per annum) -
Solutions Engineer
in Reading (£50K-£60K per annum)
Hi Bruce,
Your Article is informative, but you missed the core point in explaining what will be the Alternative for Session variables in a Distributed Server Environment. I have used session variables, but at no point of time i faced the problem of losing the value from a session variable.
Can you Explain this in detail.
Arshad Hussain.
for tker
Could you point us to some examples? That sounds like a good challange!
So what should we all be using instead. If we can't use cookies, because essientially seesion things use cookies how are you suppose to keep track of users being logged in? I guess you could tack a field on the user that says they are logged in or not but what if they change computer?? and haven't logged out of the other computer??
I Would like to know, what you suggest to use instead of Seesions.
It's difficult to maintain session state without session variables. Solutions there are. Some scripted and some 3rd party tools. Also PHP and ColdFusion have their own methods. But the bottom line is that the "cookies are evil" biscuit talk is nothing more than politics. You should inform your users that your are using cookies and what for. Nowadays browsers give you the ability to have cookies disabled for some sites and enabled for others. All the user has to do is to add your site to the "cookie-safe" list. If some paranoid user still doesn't want your site on his list (or his list is empty and he likes it that way) you should only be ready to accept it and script your site so that he can at least use whatever minimal services you can offer. If even that is not possible... well, that's his and your loss. But the world still turns and it's not the end of it.
Mind you, it's still possible to use session variables even without cookies on the client side. You just have to pass the sessionID on the url and have your scripts coded so they can use it that way. However, this brings some security issues as some guy over the user shoulder may read his session ID and hack into it on a computer next room.
Mario Figueiredo
Whenever I have created a high-traffic, browser-neutral site, I have maintained session information stored in a database. In other words, when a user logs into the site, they are assigned a 32-character identifier. This identifier travels with them as they move from page to page either on the URL or in a hidden field in a form. As they hit a page, I take the identifier and validate it against the session table. At the same time, I can check it against a LastTimeUsed field to see if too much time has passed and a LastPageUsed field to ensure that people aren't jumping into the middle of a process (both are potential signs of hacking). The other benefit is that I can build a log containing the details of the path my users are taking as they move through the web site, something quite useful if you ever need to do a usability analysis.
Does this take longer than storing state information in a session variable? Undoubtably. But a properly configured table, combined with connection pooling keeps the performance impact to a minimum. Not to mention that I can always throw more horsepower at the problem, if necessary. The web sites that I create are designed to be scalable both at the web server level (through load balancing) and at the database level. So if the activity on the web site warrented it, I would have no problem dedicating a database server to just handling the session processing.
Ultimately, I don't think that there is anything inherantly evil with using session variables. In many cases, their ease of use is too appealing to ignore. As someone else mentioned in this thread, my real purpose was to address some questions that I had been asked about session variables, especially when they are used to store ADO connection objects <<shudder>.
In response to the question of what to use instead, is there any reason not to use XML files (identified via a querystring of the filename) that are stored on the server to track user state? We've been doing this to replace cookies/sessions entirely in our web apps & haven't encountered any issues, but I was wondering if any exist?
Well heres the article on the Cookies vunerability:
http://www.wired.com/news/technology/0,1282,52115,00.html
while your at it heres a little screenshot of Windows.NET Enterprise Server[Build 3621]:
http://www.windowsbeta.de/html/newspic/3621.jpg
I know you dont want to make DevFusion a beta/hacking site but I thought you may be interested.
PHP allows cookie-less sessions... instead of storing the session ID in a cookie, it appends
?session=#SessionID#
to each url..... I thought asp.net was going to have this feature too, but I haven't found it yet....
Hotmail vulnerability? You know how they give the option to stay logged in to all .net sites, but it doesn't work keeps asking you for your password, fraking stupid thing!!
well our school doesnt let users use cookies, which is gay cause our site relies on cookies for site navigation and preferences. the only way of turning on the cookies is to disable the permissions via the registry and enable cookies again.
Is there a real alternative to cookies? on the client side all i see web developers can use is cookies. but if its restricted because so many tools are scared of them well thats it for most of us.
P.S. Did you guys hear about the HotMail Cookie vunerability?
I was just curious as to what you are suppose to do if someone don't want to turn cookies on, because their paranoid about shite that doesn't happen.
I only use session variables the way james descibes.
That's all.
yeah sure! thanks.
I don't think the author was arguing never to use sessions/cookies... just making you consider the pros and cons. In the case of logging in, using a simple session variable of boolean/(ie logged in), it not going to use up significant resources. ... the author says "There are, however, technical reasons to limit the objects that are stored."... ie, don't use sessions to store database connections, activex objects, filesystem objects etc....
at the moment, microsoft doesn't have any other way of using sessions without the use of a cookie.... although ASP.net does to some extent allow sessions to be tracked by a query parameter in the URL....
does that make any sense?
ignore my respsone i just want to hear wat an alternative would be to Sessions/cookies
So what should we all be using instead. If we can't use cookies, because essientially seesion things use cookies how are you suppose to keep track of users being logged in? I guess you could tack a field on the user that says they are logged in or not but what if they change computer?? and haven't logged out of the other computer??
I Would like to know, what you suggest to use instead of Seesions.
This thread is for discussions of When Session Variables Go Bad.