Servlet Sessions and Cookies SE-2840 Dr. Mark L. Hornick

By default, Servlets have no memory of who makes a request The HTTP protocol is stateless, meaning it does not keep track of ongoing request/response messages. Each HTTP request/response is independent of any other request/response ? SE-2840 Dr. Mark L. Hornick

Stateless Pro/Con Good for browsing and hyperlinking pages in any order without regard to past history No HTTP overhead in maintaining state Bad for applications that require complex user interaction between web pages The web application may want/need to know what page you’ve visited previous to the current page What you’ve done on previous visits SE-2840 Dr. Mark L. Hornick

A web server can ask a browser to set/read/send Cookies as part of the HTTP header HTTP request: “give me a page” Web Browser Web Server HTTP response: “OK, and BTW, store this Cookie” SE-2840 Dr. Mark L. Hornick

A Cookie is a small amount of information that can be used to implement state As a web site developer, you can store information you gather from a user on the file system of the user’s PC as a Cookie Previous date of web site access Login status . . . Cookie information Web Browser SE-2840 Dr. Mark L. Hornick

A Cookie has various properties name – the cookie name value – the value of the cookie expires – the date the cookie expires path – path in domain in which cookie is visible domain – domain the cookie is visible to secure – cookie is only available over secure connections httponly – cookie is only available via HTTP SE-2840 Dr. Mark L. Hornick

On subsequent visits, the web server can retrieve the Cookies via the HTTP header HTTP request: “give me that page again; BTW, here’s the cookie you asked me to store last time” Web Browser Web Server HTTP response: “OK, I’ll use that Cookie I gave you last time so I can customize the response” SE-2840 Dr. Mark L. Hornick

Session Protocol User's browser is given a session ID by the server Tomcat does this automatically Cookie expiration is usually fairly short; some are very long ID is included in subsequent HTTP exchanges with the server “subsequent” can be even weeks later (usually not) Server uses received session ID to locate/ retrieve corresponding session data/variables Session variables kept on server for efficiency and security Persist somewhere on the server filesystem or server db SE-2840 Dr. Mark L. Hornick

Application Session lifetime can be adjusted <?xml version="1.0" encoding="UTF-8"?> ... <servlet> <servlet-name>HelloWorld</servlet-name> <servlet-class>test.HelloWorldServlet</servlet-class> </servlet> ... Some other servlet’s defn goes here <!– Session life in minutes; 0 means end w/ browser session --> <session-config> <session-timeout>30</session-timeout> </session-config> </web-app> SE-2840 Dr. Mark L. Hornick

Tomcat handles session management for Servlets A reference to an HTTPServletRequest is created by the Container and passed to the doGet() and doPost() methods of an HTTPServlet. Session references are retrieved from the Request object. Note: You can look at Cookie objects via request.getCookies(), and set your own Cookie objects via response.addCookie() SE-2840 Dr. Mark L. Hornick

We usually initialize a ServletConfig attribute before any Servlets are initialized Solution: Use a class that implements the ServletContextListener interface This is one of 8 different Listeners The event class SE-2840 Dr. Mark L. Hornick

The contextInitialized() event handler is called by Tomcat at startup In the contextInitialized() method, we can create a ServletContext attribute that is a complex datatype: public void contextInitialized(ServletContextEvent e) { ServletContext context = e.getServletContext(); context.setAttribute(“foo”, new MyComplexType() ); } // later, any Servlet will be able to access MyComplexType via a call to getServletContext().getAttribute(“foo”); SE-2840 Dr. Mark L. Hornick

We need to register ServletContextListeners In Tomcat 7, just use the @Weblistener annotation! In Tomcat 6, you must edit the DD (web.xml): <?xml version="1.0" encoding="UTF-8"?> ... <servlet> <servlet-name>MyServlet</servlet-name> <servlet-class>test.HelloWorldServlet</servlet-class> </servlet> ... Some other servlet’s defn goes here <!– Here’s how a ServletContextListener is registered --> <listener> <listener-class>myPackage.MyContextListener</listener-class> </listener </web-app> SE-2840 Dr. Mark L. Hornick

This is what we really want User 1 hits Submit on a form page. service(request, response) Data store service(request, response) Thread 19 User 1 User1 session Thread 20 Data store User2 session Each user gets a separate session object which can be used to manage separate data stores. User 2 hits Submit on the same form page at about the same time. User 2 SE-2840 Dr. Mark L. Hornick