Java Servlets-2

Session Handling

Statelessness and Sessions

 HTTP is a stateless protocol. A client opens a connection and
requests some resource or information. The server responds with the
requested resource (if available), or sends an HTTP error status.
After closing the connection, the server does not remember any
information about the client. So, the server considers the next
request from the same client as a fresh request, with no relation to
the previous request. This is what makes HTTP a stateless protocol.
 A protocol is stateful if the response to a given request may depend
not only on the current request, but also on the outcome of previous
requests.
 Approaches to Session Tracking
 There are essentially four approaches to session tracking.
 URL rewriting
 Hidden form fields
 Cookies
 Sessions using the Secure Socket Layer (SSL)
Although above four approaches differ in implementation details, all these are based on one
simple trick- that is to exchange some form of a token between the client and the server.
This is the essence of session tracking:

This simple technique of session tracking can be adopted in different ways, based on how such
a token can be represented and exchanged. The tokens are exchanged in the above four
approaches
URL Rewriting
 In this approach, the token is embedded in each URL. In each dynamically generated page, the
server embeds an extra query parameter or extra path information, in each URL in the page.
When the client submits requests using such URLs, the token is retransmitted to the server. This
approach is called URL rewriting, as it involves rewriting URLs in the response content to embed
the extra token.
 The name of the extra parameter to pass the token for session handling as specified in the
servlet specification is jsessionid. The actual generated URLs using URL rewriting resemble the
following:
 http://www.myserver.com/WebApp1/servlet1;jsessionid=AB123D456FE789
 URL rewriting requires that all pages in application be dynamically generated. URL rewriting
cannot be enforced for static HTML pages, because the unique URL path parameter (the
jsessionid) is dynamic and differs from user to user.
 Also note that jsessionid is a path parameter, and not a query parameter (like GET request).
Query parameters are & separated name-value pairs, while the path parameter jsessionid is an
encoded resource path.
 Although the name of the parameter is jsessionid for session tracking, we can pass any other
parameter also.
Hidden Form Fields
 This approach is similar to URL rewriting. Instead of rewriting each URL, the server embeds
hidden fields in each form. When the client submits a form, the additional fields will also be
sent in the request. The server can use these parameters to establish and maintain a session.
 In this approach, the unique token is embedded within each HTML form. For example, the
following HTML specifies an input control of type hidden:
 <input type = “hidden” name = “jsessionid” value = “abcd12ef3444”>
 When the request is submitted, the server receives the token as part of the request. Note
that, similar to URL rewriting, the above content should be dynamically generated embedding
the hidden parameter. In addition, each request should include a form submission, and hence
may not be applicable to all type of pages.
 Note: The Servlet specification does not use this approach.

Cookies

 Definition: A Cookie is a small piece of textual information sent by the server to the client, stored on the client, and
returned by the client for all requests to the server.
 A Cookie contains one or more name-value pairs with certain additional attributes, which are exchanged in the
response and request headers. Web servers send a cookie by sending the Set- Cookie response header. The container can
transparently set Cookies in the response headers, and extract Cookies from request headers.
The Cookie Class
 Constructor:
Cookie(String name, String value)
 Useful Methods:
void setMaxAge(int age) //in seconds
int getMaxAge() //in seconds
void setDomain(String domain);
String getDomain()
void setPath(String path)
String getPath()
String getName()
String getValue()
 Creating a Cookie and sending it to the browser so that it can be stored on the Client m/c.
Cookie c = new Cokie(“uid”,”dev”);
c.setMaxAge(60*60); //age of cookie is 1 hr. c.setDomain(“www.myserver.com”);
//cookies will be sent back to this domain
 c.setPath(“/”); // cookies will be sent for any URL for the above domain
 response.addCookie(c); //cookie is added to the response header

 Similarly you can retrieve Cookies from requests using getCookies() method on the
HttpServletRequest interface. Possible application for setting explicit Cookies include
targeted marketing, site personalization, usage tracking etc.
 Cookie c[ ] = request.getCookies()
 We can iterate the array and retrieve the cookie names and values using getName() and
getValue() methods.
Secure Socket Layer (SSL)


 SSL is an encryption technology that runs on top of TCP/IP and below application-level protocols
such as HTTP. SSL is the technology used in HTTPS protocol. The SSL – enabled servers can
authenticate SSL- enabled clients, and use an encrypted connection between the client and the
server. In the process of establishing an encrypted connection, both the client and server
generate what are called “Session keys”, which are symmetric keys used for encrypting and
decrypting messages. Servers based on the HTTPS protocol can use the clients Symmetric key to
establish a session.
Session Tracking with the Java Servlet API
 The Servlet API also provides you with an interface, object of which let you manipulate session
lifecycle, and associate state with sessions. There are certain guidelines that make sure that
session tracking is functional irrespective of the technique used.


 Web Containers use either cookies or URL rewriting for establishing a session. While most web
containers rely on cookies alone for establishing sessions, some use Cookies by default, and use
URL rewriting when clients reject cookies. The actual creation of session is transparent to the
application programmer. That is you do not need to explicitly create, set or get cookies, or rewrite
URLs for session tracking, the only requirement is that you should encode all URLs in the response.


 The Servlet API for Session tracking consists of the following:

 Methods on the HttpServletRequest interface for creating and accessing HttpSession objects.
 HttpSession interface to represent sessions. This interface includes method to associate state with session,
and to configure and invalidate sessions.
 Methods on HttpServletResponse interface to encode URLs such that the web Container can use URL
rewriting when the Client browsers reject Cookies.
Session Creation and Tracking
 The methods from the HttpServletRequest interface for creating and tracking HttpSession
objects are:
 public HttpSession getSession(boolean create);
 public HttpSession getSession();
public interface HttpSession

Note that, as with most of the other Servlet API interfaces, web containers provide a suitable implementation
internally, and what you see is an instance obtained via the getSession() method of the
HttpServletRequest object.
The HttpSession interface has the following methods:
Methods for Session lifetime
long getCreationTime()
String getId()
long getLastAccessTime()
int getMaxInactiveInterval() // in seconds
void setMaxInactiveInterval(int interval) // in seconds Methods for associating attributes (state) with Session

void invalidate() object getAttribute(String name)

boolean isNew() Enumeration getAttributeNames()
void setAttribute(String name, Object value)
void removeAttribute (String name)