2 Ways To Implement Session Tracking

Suppose a page similar to the above one was generated when the user searched for some books. The above page has only 2 search results. There is a Form with 2 checkboxes, each next to the name of a book and a Submit button to add any selected books to the Cart.

Now suppose the user clicks on the checkbox next to book named 'Java Servlet Programming' , and then clicks on the Submit button. Note that the value of a checkbox is used in this case to store the bookID. Generally when you have many checkboxes each representing one-of-many kind of entity then the value for that checkbox differentiates between all of them. In our case since all the checkboxes represent books, each value represents a different bookID and thus a different book (one book-of-many books). This is actually a programming concept you would be familiar with in case you have done web programming.

Now coming back to the point, in case the user checked the checkbox next to the book named 'Java Servlet Programming' and then clicked the Submit button, the contents of the form are all bundled together and sent to the server side program. In our case the program is named addcart.jsp . Now suppose at any further instant when the same user is searching for more books then on a search result he might be presented with page such as the one shown below. Remember that he has already selected a book previously. So that book should be present in his Cart and now he would like to add more books.

Those of you'll who are experts in programming must have already figured out how hidden fields help in session tracking. For the rest of you'll who are like me and take more time to figure out what is happening, let me explain..

The new search result produced once again 2 new books. One book named 'Teach yourself WML Programming' with a bookID of 150 and another book named 'Teach Yourself C++' with a bookID of 160. So a form was generated with the names of these 2 books and with 2 checkboxes so that the user may select any of these books and add them to the Cart. But there is one more important thing in the form that was generated. There is a hidden input field named bookID and having a value of 100. You might have noticed that 100 was the bookID of the book named 'Java Servlet Programming' which the user had initially selected. This line describing a hidden input does not make any difference on the HTML page displayed in the browser. It would be totally invisible to the user. But within the form it makes a hell lot of a difference. This way when the user keeps adding more and more books, there would be many hidden input fields each with a different value, each representing a previously selected book. When this form is submitted to the server side program, that program would not only fetch the newly selected checkboxes (newly selected books) but also these hidden fields each representing a previously selected book by that user. Note that all the input fields have the same name bookID but their values are different. Within the server side program you would simply expect a parameter called bookID which would be an array with different values. You could extract all the values and then use them as required. It is the job of the server side program to add these lines indicating hidden fields whenever it generates a new page.

Once again..the main concept to be understood is that a hidden field displays nothing ON the HTML page. So the user who is browsing the page sees nothing unusual, but the value associated with these hidden fields can be used to hold any kind of data that you want. Only care is to be taken so that every time your server side program generates a new form, it should read all the parameters passed to it from the previous form and then add all these values as new hidden fields in any new form that it generates. Thus you could carry information from one HTML page to another and thus maintain a connection between 2 pages.

The disadvantage of session tracking is that in case you do not want the user to know what information is being passed around to maintain a session (in case that information is somewhat vital..maybe a password or something) then this method is not the best one since the user can simply select to View the Source of the HTML page and get to see all the hidden fields present in the Form.

You should be able to guess by now what URL rewriting is all about. In the above html source, the target for the form has been changed from serverprogram.jsp to serverprogram.jsp?bookID=100 . This is exactly what URL Rewriting means. The original URL which was only serverprogram.jsp has now been rewritten as serverprogram.jsp?bookID=100 . The effect of this is that the any part of the URL after the ? (question mark) is treated as extra parameters that are passed to the server side program. They are known as GET parameters. GET method of submitting forms always uses URL Rewriting. Now when the serverprogram.jsp fetches the parameters by the name bookID it would be presented with the one that was present after the ? in the URL as well as the newly selected checkboxes by the user in that Form.

Consider a general example where a user has selected 2 values, then whenever a program generates a new Form the target for that form should look something like

This sort of URL would keep on increasing as more and more values have to be carried on from one page to another.

The basic concept of URL Rewriting is that the server side program should continuously keep changing all the URLs and keep modifying them and keep increasing their length as more and more data has to be maintained between pages. The user does not see anything on the surface as such but when he clicks on a link he not only asks for that resource but because of the information after the ? in the URL he is actually sending previous data to the program.

The disadvantage of URL Rewriting (though its a minor one) is that the displayed URL in the browser is of course the rewritten URL. Thus the clean simple URL that was seen when hidden fields were used, is replaced with a one with a ? followed by many parameter values. This doesn't suit those who want the URL to look clean. Another disadvantage is that some browsers specify a limit on the length of a URL. So once the data which is being tracked exceeds beyond a certain limit, you may no longer be able to use URL Rewriting to implement session tracking. But that limit is generally large enough and so don't feel afraid to use this method. But do note that actually rewriting all the URLs within your program is not a simple task and requires some experience.

In case you are confused with what we have been doing with hidden fields and URL Rewriting, I shall sum it up once again for you. We are trying to learn methods that allow us to carry information from one HTML page to another since by default you cannot pass information from one HTML page to another. So to carry data from one page to another, we are either using hidden fields invisible to normal users or rewriting all the links on a page so that the server side program receives the old as well as new data. Thus we can maintain a session (a connection between multiple pages) for every user.