Servlet Session TrackingPersistent informationServer capabilitiesSession trackingSession tracking solutionsHidden <form> fieldsUsing hidden <form> fields, IUsing hidden <form> fields, IICookiesUsing cookiesSome more Cookie methodsWhat cookies are good forJava’s session tracking API, IJava’s session tracking API, IIUsing an HttpSessionQuitting an HttpSessionURL rewritingWhat the Container doesMore HttpServletRequest methodsSummary: Session Tracking APIOther uses of cookiesSummaryThe EndServlet Session Tracking2Persistent informationA server site typically needs to maintain two kinds of persistent (remembered) information:Information about the sessionA session starts when the user logs in or otherwise identifies himself/herself, and continues until the user logs out or completes the transaction (for example, makes a purchase)Information about the userUser information must generally be maintained much longer than session information (for example, remembering a purchase)This information must be stored on the server, for example on a file or in a database3Server capabilitiesServlets, like Applets, can be trusted or untrustedA servlet can use a unique ID to store and retrieve information about a given sessionUser information usually requires a login ID and a passwordSince servlets don’t quit between requests, any servlet can maintain information in its internal data structures, as long as the server keeps runningA trusted servlet can read and write files on the server, hence can maintain information about sessions and users even when the server is stopped and restartedAn untrusted servlet will lose all information when the servlet or server stops for any reasonThis is sometimes good enough for session informationThis is almost never good enough for user information4Session trackingHTTP is stateless: When it gets a page request, it has no memory of any previous requests from the same clientThis makes it difficult to hold a “conversation”Typical example: Putting things one at a time into a shopping cart, then checking out--each page request must somehow be associated with previous requestsThe server must be able to keep track of multiple conversations with multiple usersSession tracking is keeping track of what has gone before in this particular conversationSince HTTP is stateless, it does not do this for youYou have to do it yourself, in your servletsYou can do this by maintaining a session ID for each user5Session tracking solutionsHidden <form> fields can be used to store a unique ID for the sessionCookies are small files that the servlet can store on the client computer, and retrieve laterURL rewriting: You can append a unique ID after the URL to identify the userJava’s Session Tracking API can be used to do most of the work for you6Hidden <form> fields<input type="hidden"name="sessionID"value="...">Advantages:All you need to know is how to read servlet parametersString sessionID = getParameter("sessionID");out.println("<input type=\"hidden\"name=\"sessionID\"value=\" + sessionID + "\">");Efficient: Minimizes repeated calls to the serverDisadvantages:Information is lost when browser quits or goes to another pageUseless for maintaining persistent information about a userCan be spoofedSince the session ID must be incorporated into every HTML page, every HTML page must be dynamically generatedHidden fields are good for session tracking (holding a “conversation” with the user)--they’re simple and efficient7Using hidden <form> fields, IThe very first request that the user sends you will (typically) have null for the value of your hidden fieldWhen your servlet sees the null, it can assign a unique session ID and include it in a hidden field in the responseEach subsequent request will include this hidden fieldThe servlet can keep session information in some data structure of its own, keyed by the session IDThis is feasible because the servlet does not quit between requests, so it can maintain information in its memoryYou cannot assume the user will end the session the way you think she should (say, by logging off)If the session data is sufficiently “old,” you need to assume the user isn’t coming back, and discard the session data8Using hidden <form> fields, IIThe session ID does not have to be the only hidden fieldYou can have other fields in addition to, or instead of, a session ID fieldThis might be a good way to keep track of small amounts of simple information during a sessionHidden fields are not particularly well suited to holding complex or structured informationIn all cases, hidden <form> fields are good only for storing session informationInformation in servlet data structures will eventually be lost (when the servlet quits) or get old and be discarded9CookiesA cookie is a small bit of text sent to the client that can be read again laterLimitations (for the protection of the client):Not more than 4KB per cookie (more than enough in general)Not more than 20 cookies per siteNot more than 300 cookies totalCookies are not a security threatCookies can be a privacy threat Cookies can be used to customize advertisementsOutlook Express allows cookies to be embedded in emailA servlet can read your cookiesIncompetent companies might keep your credit card info in a cookieNetscape and Firefox let you refuse cookies to sites other than that to which you connected10Using cookiesimport javax.servlet.http.*;Constructor: Cookie(String name, String value)Assuming request is an HttpServletRequest and response is an HttpServletResponse,response.addCookie(cookie);Cookie[ ] cookies = request.getCookies();String name = cookies[i].getName();String value = cookies[i].getValue();There are, of course, many more methods in the HttpServletRequest, HttpServletResponse, andCookie classes in the javax.servlet.http package11Some more Cookie methodspublic void setComment(Stringpurpose )public String getComment()public void setMaxAge(intexpiry )public int getMaxAge()Max age in seconds after which cookie will expireIf expiry is negative, delete when browser exitsIf expiry is zero, delete cookie immediatelysetSecure(booleanflag)public boolean getSecure()Indicates to the browser whether the cookie should only be sent using a
View Full Document
Unlocking...