http session state management for iis and apache - cookie, and cookieless url query parameter or hidden input form field

http session state management for iis and apache - cookie, and cookieless url query parameter or hidden input form field is a survey of the available techniques for managing client browser sessions under the stateless http protocol. Note that state cannot be maintained by a static html page but it can be maintained across such a page as long as the end points are dynamic cgi, isapi, asp, asp.net, or php scripts. This is true whether the pages are deployed on an iis or apache server.

The basis of the difficulty in maintaining session state is that the http protocol is stateless. It has no concept of state and thus lacks any defined mechanisms for maintaining state on behalf of any internet application.

For static web sites, the characteristic stateless nature of the http protocol poses no problems. It is only when the original use of the protocol is extended to create user centric internet applications that this statelessness becomes a design restriction.

Applications such as chat boards, blogs, shopping carts, b2b ecommerce, portal, web mail and membership subscription management all require the server to be able to recognise individual users as distinct from other users and respond correctly for that user uniquely. This is true whether or not user login is required. For example, using a shopping cart may not require a user login, but it does require that the contents of the shopping cart be tied to a particular user session.

cookies
Browser cookies have been traditionally the easiest place to store user unique session data. Every modern browser is capable of handling cookies properly. The storage burden is handled by the client. No database programming is required, the server application only needs to be able to read and set cookies during the response phase. Once a cookie has been sent to a client during a session, the cookie will be returned as a header with every subsequent request to the server to which that cookie corresponds. They are generally available to the application at any time that it becomes necessary, but may be ignored when irrelevant to the current operation.

As you might guess, cookies are particularly attractive as a means of maintaining session identity. The downside is that users are becoming resistant to the use of cookies due to security concerns as explained in another article about hotlink prevention. The result is that if cookies are chosen to maintain session state this requirement must be explicitly detailed on your site, and the application must test that cookies are turned on for each new session. It may be found that some users are more accepting of session cookies than persistent cookies. A session cookie is not stored on the user system and will disappear once all browser windows are shutdown. These are created by simply not specifying an expiry in the cookie properties. Other cookie properties that are of interest to the application designer are the cookie security property and the cookie path property.

cookieless
An alternative to cookies for passing session data is the use of hidden input fields in forms. In this technique, one or more pieces of data may be passed to the client by the server in a html form in one or more hidden input fields. This data is intended to be returned to the server unchanged when the user clicks on the submit button that is included in the form. In the extreme case, it is possible to include a form on a page that only has hidden fields. This usage requires that every possible path out of the page that targets a page on the origin server trigger a submit action. The method property of the form may use either the post or get http verbs. Using the post method results in a cleaner appearance of the url displayed in the browser type in bar. If the get verb is used, then all of the inputs, including the hidden inputs will be appended as query parameters to the url sent to the server and displayed in the type in bar. When parameters are displayed in the url, it is very tempting for advanced users to experiment with the effect of editing the parameters and resubmitting the link.

The third option for preserving session state is the use of query parameters in requests passed to the server. This entails that the server modify every link url in a page to append the tracking data for a particular as query parameters. At first glance, this might appear to be unusable with forms employing the post verb as its method property. However, it appears that both the request parameters and the body entity (form data) are passed to the underlying scripting engines registered as html handlers on the server. The downside, again, is that the url in the type in bar is fairly messy and available for experimentation by users.

persistence
Finally, there are limitations that are common to both the second and third methods of maintaining session state. First, they are extremely labor and resource intensive. The session information must be persisted between page views. This is usually done by storing the information in a database. The session identifier that matches a particular session with the additional session information in the database must be passed to and from the client and server on every html page. If this is not done, the session becomes orphaned. This then requires that every page is dynamic, any intervening static page will cause the session to be orphaned. A similar problem is manifested when a user uses the back button to backup past the point where the session has been established. When this happens, the session is lost and a new session must be started. The exception is when the user also uses the forward button again to return to a page that is tied to the original session. Second, the session information is becomes part of the page identity. This opens up the possiblity that the page will be bookmarked or forwarded with session information will be invalid by the time it is used again. Furthermore, if the session information includes authentication information, then it potentially grants authority to any user who accesses the url.

security
And, no matter which of these methods are used, consideration must be given to session data validation. Remember, the data is passed back to the server from a client which may or may not have modified it. Thus, it is a security best practice to validate the data against expected values and reject any data that is suspect. This revalidation must occurr on every use of the data. If this security requirement is ignored, sooner or later, a malicious user will take full advantage of this shortcoming.

If the reader has arrived at the conclusion that maintaining session state reliably is difficult in a production environment where control of the end client is not possible then the correct conclusion has been made. Because of the popularity of internet, and the growth of internet applications, session state management has become the holy grail of site architects. There are too few tools to achieve it, and yet it is an absolute requirement for many uses.

Search terms which will yield additional information on the techniques for session management include the following:

• http stateless protocol
• session management
• session variable
• iis session object
• session identifiers
• session cookies
• cookieless session
• session url parameter
• session hidden form data field
• netscape cookie protocol
• shopping cart session
• application session
• asp session
• php session

to link to this page from your pages, copy the code from the box below and add it to the your page where you want the link to appear