The JSP Files (Part 6) - State of Grace

The JSP Files (part 6): State Of Grace By Vikram Vaswani and Harish Kamath This article copyright Melonfire 2000−2002. All rights reserved. Table of Contents A Perfect State .1 Wasted, Dude! .2 A Few Ground Rules 3 Learning To Write 4 .And Read 8 What's In A Name? .10 Plan B .13 Session Dissection 14 Access Denied 16 The JSP Files (part 6): State Of Grace i A Perfect State Over the past few weeks, you've learned a great deal about the various control structures and objects available in JSP. You've see how to retrieve information posted in an online form, and connect your JSP document to a database for dynamic content generation. This week in The JSP Files, we're going to tackle yet another very interesting topic − the problem of maintaining "state" on a Web site. We'll be looking at two common solutions to this problem − cookies and server−based sessions − and using simple examples to illustrate the JSP constructs available to help you identify and track client requests on your Web site. You'll also learn more than you want to know about what exactly "maintaining state" actually means, the advantages and disadvantages of each of the approaches just described .and, if we're doing our job right, get a laugh or two out of the whole exercise. A Perfect State 1 Wasted, Dude! It's one of the things geeks say to each other when they want to impress the young women in earshot: "HTTP is a stateless protocol, and the Internet is a stateless development environment". In simple language, all this means is that the HyperText Transfer Protocol, which is the backbone of the Web, is unable to retain a memory of the identity of each client that connects to a Web site, and therefore treats each request for a Web page as a unique and independent connection, with no relationship whatsoever to the connections that preceded it − very similar to the behaviour of some of today's more adventurous teenagers, who get drunk every night, wake up the next morning with no memory at all of what happened, and go out again in the evening to do the same thing all over again . Now, so long as you're aimlessly surfing from one site to another, this works without a problem. But what if you've decided to buy a few discs from CDNow.com? In a "stateless environment", it would be very difficult to keep track of all the items you've shortlisted for purchase, as the stateless nature of the HTTP protocol would make it impossible to keep track of the items selected. Consequently, what is required is a method that makes it possible to "maintain state", something that allows client connections to be tracked and connection−specific data to be maintained. And thus came about "cookies", which allowed Web sites to store client−specific information in a file on the client system, and access the information in the file whenever required. So, in the shopping cart example above, the items selected would be added to the cookie, and would be retrieved and presented to the customer in a consolidated list during the billing process. Why are they called "cookies"? The PR agency handling the account was obviously asleep at the wheel. Wasted, Dude! 2 A Few Ground Rules Since cookies are used to record information about your activities on a particular site, they can only be read by the site that created them. For example, Yahoo and Deja.com store your username in a cookie on your hard drive and use this information to automatically fill in log−in forms the next time you visit their Web sites. It's kinda like going to a chic restaurant, and having the maitre'd call you by name (something which hasn't happened to us of late!) Before getting into the nitty−gritty of cookie technology, a few ground rules are in order: 1. A single domain cannot set more than twenty cookies. A single cookie cannot exceed 4 KB in size. The maximum number of cookies that may be set is 300. 2. The most common method of transmitting a cookie to a client is via the "Set−Cookie" HTTP header. 3. A cookie usually possesses five types of attributes. The first of these is a NAME=VALUE pair, used to store information such as a username, email address or credit−card number. The NAME is a string used to identify the cookie, while the VALUE is the data to be stored in the cookie. For example, clarkkent=superman The EXPIRES attribute defines the date on which the cookie is automatically removed from the system. The date must be in the format "weekday, dd−mon−yy hh:mm:ss GMT". For example, expires="Sun, 31−Dec−2030 17:51:06 GMT" Cookies without a specifically defined expiry date remain active for so long as the browser remains open, and are destroyed once the browser is closed. You can delete an existing cookie be setting this attribute to a date in the past. The PATH attribute is used to set the top−level directory on the Web server from which cookies can be accessed. In most cases, this is set to path=/ to ensure that the cookie can be accessed by each and every document on the server. The DOMAIN attribute is used to specify the domain which the cookie is linked to, and the SECURE attribute indicates that a cookie should only be set if there exists a secure protocol between the browser and the server. 4. Of all the five attributes, the first is the only one that is not optional. 5. Every good browser offers users the option to disable cookies. If a user decides to exercise his or her right to do so, your cookies will not be stored, and any attempt to access them will fail. Users who do this are usually career criminals or tax evaders. A Few Ground Rules 3 Learning To Write . Now, there are innumerable ways to go about creating and reading cookies on a client browser − you can use Javascript, you can use PHP, you can use any of the wonderful programming languages out there. However, our concern here is with JSP − so let's take a look at an example which demonstrates how to read and write a cookie. This is a simple hit counter which creates a cookie the first time the user visits the Web page, and then increments the counter on each subsequent visit. <% // counter.jsp // declare some variables Cookie cookieCounter = null; // the cookie you want String cookieName = "counter"; int cookieFound = 0; // a few more useful variables String tempString; int count=0; // get an array of all cookies available on client Cookie[] cookies = request.getCookies(); // iterate through array looking for your cookie for(int i=0; i<cookies.length; i++) { cookieCounter = cookies[i]; if (cookieName.equals(cookieCounter.getName())) { cookieFound = 1; break; } } // if found if(cookieFound == 1) { // get the counter value as string tempString = cookieCounter.getValue(); Learning To Write . 4 // convert it to a number count = Integer.parseInt(tempString); // increment it count++; // back to a string tempString = Integer.toString(count); // store it in the cookie for future use cookieCounter.setValue(tempString); // set some other attributes cookieCounter.setMaxAge(300); cookieCounter.setPath("/"); // send cookie to client response.addCookie(cookieCounter); } // if not found else { // create a new cookie with counter 0 Cookie alpha = null; alpha = new Cookie("counter", "0"); alpha.setMaxAge(300); alpha.setPath("/"); response.addCookie(alpha); } %> <html> <head> <basefont face="Arial"> </head> <body> <% // display appropriate message if (count > 0) { out.println("You have visited this page " + count + " time(s)! Don't you have anything else to do, you bum?! "); } else { The JSP Files (part 6): State Of Grace Learning To Write . 5 out.println("Welcome, stranger!"); } %> </body> </html> Sure, it looks a little complicated − but it won't once we break it down for you. The first thing you need to know is how to create a cookie on the client − this is accomplished with the following code: <% Cookie alpha = null; alpha = new Cookie("counter", "0"); alpha.setMaxAge(300); alpha.setPath("/"); response.addCookie(alpha); %> The first two lines create a new instance of a Cookie object − "alpha". The cookie variable "counter" is then initialized and set to the string "0". Next, the setMaxAge() and setPath() methods of the Cookie object are used to set the expiry date (in seconds) and the cookie's availability, respectively. Finally, a call to the Response object's addCookie() method takes care of actually transmitting the cookie to the client. As already mentioned, the only attribute which is not optional is the NAME=VALUE pair. If you'd like your cookie to remain available even after the user closes the browser, you should explicitly set an expiry date; if not, the cookie will be destroyed once the browser is closed. The Cookie object also comes with a couple of other interesting methods. setValue(someString) − sets the value of the cookie to someString getValue() − returns the current value of the cookie setPath(someURL) − sets the PATH attribute of a cookie to someURL getPath() − returns the current value of the PATH attribute setMaxAge(someSeconds) − sets the EXPIRES attribute of the cookie, in seconds getMaxAge() − returns the current value of the EXPIRES attribute The JSP Files (part 6): State Of Grace Learning To Write . 6 setDomain(someURL) − sets the DOMAIN attribute of the cookie getDomain() − returns the current value of the DOMAIN attribute setSecure(flag) − sets the SECURE attribute of the cookie as either true or false getSecure() − returns the current value of the SECURE attribute Note that you can only save string values in a cookie with setValue() − which entails a lot of string−to−number−to−string conversions if you actually want to store a number (as in this example). The JSP Files (part 6): State Of Grace Learning To Write . 7 .And Read So that takes care of writing a cookie − but how about reading it? Here's the code. <% // declare some variables Cookie cookieCounter = null; // the cookie you want String cookieName = "counter"; int cookieFound = 0; // a few more useful variables String tempString; int count=0; // get an array of all cookies available on client Cookie[] cookies = request.getCookies(); // iterate through array looking for your cookie for(int i=0; i<cookies.length; i++) { cookieCounter = cookies[i]; if (cookieName.equals(cookieCounter.getName())) { cookieFound = 1; break; } } %> Before you can read the cookie, you need to find it on the client's hard drive. Since JSP does not currently allow you to directly locate and identify the cookie by name, you need to iterate through all available cookies until you find the one you're looking for. In the example above, the "for" loop does just that; if and when it finds the cookie, it sets the "cookieFound" variable to 1 and breaks out of the loop. At this point, the cookie is stored in the Cookie object "cookieCounter". You can then use the getValue() object method to get the current value of the cookie variable, and use it in your script. .And Read 8 [...]... register the variables You can then use the getValue() method to retrieve the values of the session variables automatically An important point to be noted here is that it is necessary to typecast the session variable while using getValue() − in the example above, we've specifically stated the type of the variable in parentheses before Session Dissection 14 The JSP Files (part 6): State Of Grace assigning... of the server−side language (once the cookie has been saved to the client's hard drive, you can read it using JavaScript, or PHP, or JSP, or ) The only problem: it is dependent on the cookie being accepted by the client And so, another common approach is the use of a "session" to store specific bits of information when a client visits a Web site; this session data is preserved for the duration of the. .. ("login .jsp" ) once you submit the form "login .jsp" creates a session to store the name you entered, and offers a link to "rootshell .jsp" , which is the sensitive file to be protected So long as the session is active, any attempt to access the page "rootshell .jsp" will succeed On the flip side, if a session is not active, any attempt to access "rootshell .jsp" by bypassing the initial form will fail, and the. .. here for root access"); %> And here's the top−secret page Your name This is the initial.. .The JSP Files (part 6): State Of Grace . value of the EXPIRES attribute The JSP Files (part 6): State Of Grace Learning To Write . 6 setDomain(someURL) − sets the DOMAIN attribute of the cookie. Denied 16 The JSP Files (part 6): State Of Grace i A Perfect State Over the past few weeks, you've learned a great deal about the various control