Blogging on Demand #2

Every now and again I go through my referral logs to see if there's anything interesting bringing people to my site, and if so, I've started writing a little bit about them.

I've previously written about the arraylist.Copy method after someone landed on my site looking for it in Yahoo.

This week someone landed here looking for "sessionid tutorial example vb.net" from Yahoo.


Session.SessionID returns a String, which is the web server's internal identifier of the current session for that particular user. It is this number that gets passed around in cookies and whatnot that allows ASP.NET applications to manage session state.

Although 99% of the time, normal people will never get to see their sessionID getting passed about (it's all done in the background) there are a couple of situations where the session ID is passed in the request's URL. The most common ones are:

Mobile web forms
Although mobile web apps are getting more widely used out in the real world (I've even written one or two myself), some things, like cookie handling, haven't been adopted in any kind of standard way. Some browsers on some devices have cookie handlig, but not all. As a result, the only way to tie the requests from the browser to the session state being managed on the web server is through the URL. If you ever navigate to a mobile webapp from Internet explorer, you'll notice that the URL in the address bar changes to something like "http://localhost/MyMobileApp/(biiig long number here)/Form1.aspx". The big long number being passed abut is the session ID.

Cookieless Sessions
In the same way that mobile web apps pass the session ID in the request URL, normal web browsers do that as well if you configure your app to use cookieless sessions. Kinda makes sense, really. If your user can't receive cookies, then you need some mechanism to associate the user with the session object.

There are one or two security issues, as well as aesthetic issues when it comes to passing session ID's in the URL. As far as security goes, putting the session ID in the URL makes it easier to copy/paste that URL into their browser and hijack someone's session. Not good, particularly if you have a website with restricted/controlled access areas.

Aesthetically, as well, it looks ugly. Big long URLs are bad enough, but put a session ID in there, in brackets, and that's just getting silly. If you've built your app properly, then if someone comes back with an invalid session ID, then nothing'll happen. Your app will gracefully handle the situation, and your user can continue as normal. I only mention this because of one of the other problems with cookieless sessions - if your app doesn't handle an invalid session ID properly, then you're going to have a number of users upset with you because they can't bookmark your site.

Well, that's about all you can say about SessionID. It's a member of the System.Web.SessionState.HttpSessionState class, and is used by the server to differentiate bewteen user sessions.

That is all.