Sessions, Client Side Javascript and Correlation

8 Jun

Recently I one of my good friend asked me a question ” How do I correlate the session id information which is created via javascript with LoadRunner”

Well this was an interesting question and of course he was not the first one to ask about this, there are lot many people who had asked this question in various online forums like LinkedIn etc.So I thought let me write some of my thoughts on this,

Http protocol as known today technically is the stateless protocol.It means that it cannot distinguish between the first time visitor or a regular visitors.It just forgets the client as soon as request is serviced and this behavior of the HTTP creates the need for maintaining the session information.This is reason as why session generation and maintenance is handled by the programming languages.

Session management with http is normally done by using below techniques

URL Rewriting

With this method of session handling, session ids are often appended to the query string of the url and the query string looks something like below,…etc

Depending on the way we design the application, session information can pass as query string parameters namely in key/value or name/value format and this applies even to session ids.Also at times this method is often used whenever client do not accept cookies for some reason.In fact some servers like web logic etc automatically switches the session handling to this method once they detect that client is not accepting cookies from the server.

URL Rewriting often  leads to ugly urls  so at times these url’s are hidden from the client and replaced by good and short looking url’s.This trick is done by server side modules which can rewrite the urls on the fly(Apache mod rewrite is one such example).The best way to identify if your application uses this method of session handling is to block all cookies via browser and test it.Also there exists some restriction on the length of the url with regard to some browsers like IE.IE cannot take length of the url beyond 2k bytes.

Also using this method at times could lead to security hole as referrer tag are leaked if one navigates in the via same browser window.

Hidden fields

In this method of session handling, extra form fields are sent to the client and these extra form fields always hidden from the client.The hidden fields look something like,

<input type=’hidden’ name=’id’ value=’a’/>

Hidden fields are also used to maintain the page information across the pages and is one of the frequently used method  to maintain session information.The good thing of this method is that url’s remains short and large data can be passed over the server for processing.In addition to session information, hidden fields can also be used to persists the client entered data across the pages.


I feel this is simplest way to maintain the session information and definitely better than url rewriting and hidden fields.Most application as soon as they receive first request, server drop the cookies on the client computer and later on for every subsequent request , they check for its existence in client requests with regard to  further communication.So if we as performance engineer comment out these cookies, then obviously we are asking application to do more work and is definitely a wrong load model as well.Cookies are never commented out in real world scenario and should not be commented out during load testing as well.

HttpSession Objects

These are objects which are created on the server side to store session information.These session objects are never passed on the client.However there might be cases where unique identifier namely jsessionid is appended to the url and send across to the client,in case client do not accept cookies.In this method session is stored in the memory and if the session object is too large, then it gets serialized to the file system or to some disk.Personally I have seen good performance with this method of session handling whenever the user base is small.How ever storing session in the httpsession objects could lead to heavy resources consumption given that sessions cannot moved outside the servers.In other words, application using this method of session handling cannot effectively use  server farms or web gardens as sessions are inproc. Also using this method leads to inefficient usage of load balancers.

Now having discussed some basics on sessions,so where does client side javascript fit in all these ?

Storing or accessing the session via javascript is all big security hole. I don’t recollect even a single instance where javascript was used to maintain sessions for any of my projects.So I doubt if any one uses Javascript to create session or store session information.

So with javascript can we create or access the sessions or session ids ?

I would say yes.Javascript provides rich set of methods to access url’s/cookies/hidden fields and with Ajax , we can definitely create and maintain the session information with javascript.However interesting point here is that what if client turns off javascript in their browsers ? 

Knowing  these risks, do you still believe that people are going to use Javascript to store session information ?

If yes, then probably I need to write another post on how to get around these type of cases given that no load generating tool existing in the market today can execute or capture javascript events correctly as done by the browsers in real sense.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: