Transcript Managing Users` States

CSC 2720
Building Web Applications
Managing Users' States –
Cookies, URL-Rewriting, Hidden Fields and
Session Management APIs
Login Failed
Successful
Login
login.jsp
Logout
show_acct.jsp
bye.jsp
 A typical web application involves more than one
servlet. How should these servlets share data with
one another?
 e.g., How does show_acct.jsp knows which user has
successfully logged in and which user's account to
show?
HTTP – A Stateless Protocol
 Web servers don't retain information about users
between requests.
 Each HTTP request is like a phone call and the server
hangs up the phone after serving each request.
 Web application developers need alternative
methods for maintaining users' states.
 Cookies
 URL-rewriting
 Hidden fields in HTML forms
 Platform/language specific APIs for managing sessions
Architecture of Stand-Alone Program
State Information
(Data)
User Interface and
Presentation
Program Logic
All the components of the program work in the same memory
space and share data.
There is only one copy of data per application.
Architecture of Web Application
Client A
(User Interface and
Presentation)
Web App
(Business Logic)
Client B
(User Interface and
Presentation)
Clients and servers have their own memory space.
Architecture of Web Application
Client A
(User Interface and
Presentation)
Web App
(Business Logic)
Client B
(User Interface and
Presentation)
?
How and where should we keep the state
information that uniquely define an
application for client A and B respectively?
State Information
(Data)
Architecture of Web Application
State info
Client A
(User Interface and
Presentation)
Web App
(Business Logic)
State info
Client B
(User Interface and
Presentation)
Approach #1:
 Clients kept the state info
 Clients sent the state info back to the server-side program in every request
 Server-side programs update the state info and sends them back to the clients to keep
Architecture of Web Application
id1
Client A
(User Interface and
Presentation)
Web App
(Business Logic)
id2
Client B
(User Interface and
Presentation)
id1
id2
State info
State info
Approach #2:
 Server keeps the state info
 Clients keep a unique ID (generated by the server)
 Clients pass ID back to server on every request
 Server-side programs look up state info stored in the local memory based on received ID.
Maintaining States and Session Tracking
Approach #1 can be achieved through
 Cookies
 URL-rewriting
 Hidden Fields in Form
 Disadvantages: Require sending large amount of data
which may include sensitive info between the client and the
server on every request.
Approach #2 can be achieved through
 High-level APIs for maintaining sessions by the Servlet
Cookies
 HTTP cookies are data sent by a server (on behalf of the
server-side programs) to a browser to keep.
 The browser keeps the data for a period of time.
 The browser sends back the cookies to the server on every
request (unless the cookie support is turned off).
 The cookies are embedded in the HTTP header (and
therefore not visible to the user).
Cookies
 Shortcomings
 User may turn off cookies support.
 Data are kept with the browser
 Users using the same browser share the cookies.
 Limited number of cookies (20) per server/domain and
limited size (4k bytes) per cookie
 Client can temper with cookies
 Modify cookie files, use JavaScript to create/modify cookies, etc.
 Notes
 Don't always rely on cookies as the client may have
turned off cookies support.
 Don't store sensitive info in cookies
URL-Rewriting
 Data are appended to the URL
 e.g.:
http://www.xyz.com/servletName?name=value&name2=value2
 Data are kept along with the "page"
 Each time, a server-side program needs to
 Retrieve all state info from the URL
 Update the state info
 Write the state info back to the URL in all links that appears in the
page (including the URL in the form "action" attribute)
 Shortcoming:
 Limited number of characters in an URL
 Not suitable for sensitive info
Hidden Fields in HTML Form
 Data are encoded as hidden fields in HTML form as:
<input type="hidden" name="username" value="CJ Yuan" />
 Shortcoming: Always need a form.
<%-- In login.jsp --%>
<% String attemptParam = request.getParameter("attempt");
int attempt = 0;
if (attemptParam != null)
attempt = Integer.parseInt(attemptParam) + 1;
// Assume no error in conversion
%>
<form action="login.jsp" method="POST">
<label>Login ID</label><input type="text" name="id" /><br />
<label>Password</label><input type="password" name="pwd" />
<br />
<input type="submit" value="Login"/>
<input type="hidden" name="attempt" value="<%=attempt%>" />
</form>
Session (Supported by the Servlet Container)
 A session is a period of time in which all activities
happened within the period by the same client is
considered "related" (typically belong to the same
application.)
 Session Tracking – keeping track of users as they traverse
from one web page or servlet to another within a website
(or using a web application).
 Clients keep a unique "session id" generated by the server.
 The "session id" is sent back and forth between the client
and the server through methods like cookies or URLrewriting.
Creating and Obtaining Session object
 HttpServletRequest
 public HttpSession getSession();
 Returns the current session object. If there is no current
session object, create a new one and return it.
// e.g., in processRequest/doGet/doPost methods
HttpSession session = request.getSession();
 In JSP, the "session" object is implicitly made available.
 We can store data to be shared among servlets/JSP in the
session object.
Session object: Storing and Accessing Data
 HttpSession
 public void setAttribute(String name, Object value);
 public Object getAttribute(String name);
 public void removeAttribute(String value);
 Works like a hash table except that the key is a string.
 You do not have to know what the generated session ID is.
// We can store objects in the session object
session.setAttribute("username", name);
session.setAttribute("login-attempt", new Integer(0));
String name = (String)session.getAttribute("username");
session.removeAttribute("username");
More HttpSession Methods
 public Enumeration getAttributeNames();
 Returns names of all attributes set in the session object
 public String getID();
 Returns the unique session ID generated by the servlet
container.
 public boolean isNew();
 Returns true if the clients does not yet know about the
session.
 public void invalidate();
 Makes the session object invalid. Future use to this
session object will result in IllegalStateException thrown.
More HttpSession Methods
 public void setMaxInactiveInterval(int
seconds)
 Sets how long the session object can stay inactive before
becoming invalid.
 Any user request to the resources that belong to the same web
application would activate the session object.
 By default, the maximum inactive interval is set to 1800 seconds
(30 min)
 If seconds is -1, then the session will only terminate when the
client terminates (when the user closes the browser).
 public int getMaxInactiveInterval();
 Returns the max inactive interval in seconds.
Using Session When Cookies is Disabled
 Use URL-rewriting method to pass session ID to
client
 Use when cookies is disabled.
 HttpResponse
 public String encodeURL(String url);
 Call this method to create a new URL string with
session ID appended to "url".
 Only append when necessary (e.g., when the client's
browser does not support cookies or turns off
cookies support).
Combined Use
 All of Cookies, URL-rewriting, Hidden Fields, and
Session objects can be simultaneously used in a
web application.
 Cookies: Can persist data for long period but is not
suitable for keeping sensitive data or large amount of
data.
 URL-rewriting: Keep data along with page
 Hidden Fields: Keep data along with page (can keep
more data but requires HTML form)
 Session Objects: Keep "short-live" data shared among
the servlets within a web application for a particular
client.
Summary
 Session Management




Cookies
URL-Rewriting
Hidden Fields in HTML Form
High level APIs in Java and HttpSession Objects.
 Reference
 http://en.wikipedia.org/wiki/HTTP_cookie
Sending Cookies to Browser
 Standard approach:
Cookie c = new Cookie("name", "value");
c.setMaxAge(...); // Means cookie persists on disk
// Set other attributes.
response.addCookie(c);
 Simplified approach:
 Use LongLivedCookie class:
public class LongLivedCookie extends Cookie {
public static final int SECONDS_PER_YEAR =
60*60*24*365;
public LongLivedCookie(String name, String value) {
super(name, value);
setMaxAge(SECONDS_PER_YEAR);
}
}
Reading Cookies from Browser
 Standard approach:
Cookie[] cookies = request.getCookies();
if (cookies != null) {
for(int i=0; i<cookies.length; i++) {
Cookie c = cookies[i];
if (c.getName().equals("someName")) {
doSomethingWith(c);
break;
}
}
}
Reading Cookies from Browser
public static String getCookieValue(
Cookie[] cookies, String cookieName,
String defaultVal)
{
if (cookies != null) {
for(int i=0; i<cookies.length; i++) {
Cookie cookie = cookies[i];
if (cookieName.equals(cookie.getName()))
return(cookie.getValue());
}
}
return(defaultVal);
}
Methods in the javax.servlet.http.Cookie
 getDomain/setDomain
 This property indicates the domain within which this cookie should
be presented. (Default is the domain of the current server)
 getMaxAge/setMaxAge
 Gets/sets the cookie expiration time in seconds
 A negative value means that the cookie is not stored persistently
and will be deleted when the browser exits. (Default)
 A zero value causes the cookie to be deleted.
 getName
 Gets the cookie name.
 Cookie name can only be set through the constructor.
Methods in the javax.servlet.http.Cookie
 getPath/setPath
 Gets/sets the path to which the cookie applies.
 The cookie is visible to all the pages in the directory you specify,
and all the pages in that directory's subdirectories. A cookie's path
must include the servlet that set the cookie
 getSecure/setSecure
 Gets/sets a flag that indicates whether the cookie should only be
sent using a secure protocol, such as HTTPS or SSL.
 getValue/setValue
 Gets/sets value associated with the cookie.
 If you use a binary value, you may want to use BASE64 encoding.
 With Version 0 cookies, values should not contain white space,
brackets, parentheses, equals signs, commas, double quotes,
slashes, question marks, at signs, colons, and semicolons. Empty
values may not behave the same way on all browsers.