Servlet Session Tracking API: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
 
(12 intermediate revisions by the same user not shown)
Line 1: Line 1:
=External=
* https://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpSession.html
=Internal=
=Internal=
* [[HTTP_Session#Servlet_Session_Tracking_API|HTTP Session]]
* [[HTTP_Session#Servlet_Session_Tracking_API|HTTP Session]]
* [[Servlet#Subjects|Servlet]]


=Overview=
=Overview=
Line 10: Line 15:
=Example=
=Example=


<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
{{Internal|Session Servlet Example|Session Servlet Example}}
:[[Playground Session Servlet Example]]
</blockquote>


=Establishing a Session=
=Establishing a Session=
Line 29: Line 32:
:https://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getSession--<br>
:https://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getSession--<br>
</blockquote>
</blockquote>
=Session ID and JSESSIONID=
The session ID can be obtain with <tt>HttpSession.getId()</tt>. The string value is the same that is sent back by the server as the value of the "Set-Cookie" header.


==Browser/Server Conversation on Session Establishment==
==Browser/Server Conversation on Session Establishment==
Line 71: Line 78:
The server-side code may choose to create a new session and send a new session ID with the Set-Cookie header. The browser will comply and replace the obsolete session ID.
The server-side code may choose to create a new session and send a new session ID with the Set-Cookie header. The browser will comply and replace the obsolete session ID.


=Destroying a Session=
=Invalidating a Session=
 
A session can be invalidated (destroyed) with the <tt>HttpSession.invalidateSession()</tt> API call. Upon invalidation, the session disappears from memory and the JSESSIONID cookies residing on browsers become obsolete. It is good practice to reset the invalid JSESSIONID cookie on invoking browser after invalidation. Am example of how to do that is presented below:
 
<pre>
//
// remove JSESSIONID from browser
//
 
Cookie oldJSessionIdCookie = context.getCookie("JSESSIONID");
Cookie cookie = new Cookie(oldJSessionIdCookie.getName(), null);
cookie.setPath(oldJSessionIdCookie.getPath());
cookie.setMaxAge(0);
HttpServletResponse response = ...
response.addCookie(cookie);
</pre>


=Authentication and Session=
=Authentication and Session=
Line 97: Line 119:
</pre>
</pre>


==JBossWeb/Tomcat HTTP Session Implementation Details==


=ServletContext=
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[JBossWeb/Tomcat HTTP Session Implementation Details]]
</blockquote>


The <tt>ServletContext</tt> defines a set of methods that a servlet uses to communicate with its servlet container, for example, to get the MIME type of a file, dispatch requests, or write to a log file.
=Session Replication=


There is one context per "web application" per Java Virtual Machine. In the case of a web application marked "distributed" in its deployment descriptor, there will be one context instance for each virtual machine. In this situation, the context cannot be used as a location to share global information (because the information won't be truly global). Use an external resource like a database instead.
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
 
:[[HTTP Session Replication]]
The <tt>ServletContext</tt> object is contained within the <tt>ServletConfig</tt> object, which the Web server provides the servlet when the servlet is initialized.
</blockquote>
 
<font color=red>To allow web applications to operate independently, session are scoped at the web application level. This means each <tt>ServletContext</tt> maintains its own pool of <tt>HttpSession</tt> instances, and a servlet running inside one context cannot access session information saved by a servlet in another context. </font>

Latest revision as of 18:14, 27 November 2017

External

Internal

Overview

The servlet API provides facilities that help the developer to track the servlet's session. Servlets have built-in session tracking. The level of support, however, depends on the web server. Most servers support session tracking through the use of persistent cookies, and when the client doesn't accept cookies, the servers could revert to URL rewriting.

JBossWeb and Tomcat manage HTTP sessions for web applications.

Example

Session Servlet Example

Establishing a Session


To ensure that a session is properly maintained, the getSession() method must be called at least once before committing the response. Sessions are not created automatically, unless we invoke HttpServletRequest.getSession(), which is equivalent with HttpServletRequest.getSession(true).

Once the server runtime creates the HTTP session, it places the "Set-Cookie: JSESSIONID=8EHFGusUPlelgRkT9wt8IliH; Path=/session-servlet" header in the response. This header informs the browser that from now on, the user has a session on the server.

Subsequent browser calls include a "Cookie" header containing the session ID ("Cookie: JSESSIONID=8EHFGusUPlelgRkT9wt8IliH"). This ID allows the server to look up the corresponding session and associate it wit the request.

API

https://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getSession--

Session ID and JSESSIONID

The session ID can be obtain with HttpSession.getId(). The string value is the same that is sent back by the server as the value of the "Set-Cookie" header.

Browser/Server Conversation on Session Establishment

The first HTTP response that initiates the session and plants the cookie on the browser:

HTTP/1.x 200 OK
Date: Thu, 22 Oct 2009 14:17:28 GMT
Server: Apache/2.2.6 (Unix) mod_ssl/2.2.6 a/journals/zihuatanejo.html$ mod_jk/1.2.26
X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5
Set-Cookie: JSESSIONID=71867A63768B13C9B58E623401BE7C57.tastcomapp01; Path=/
Cache-Control: no-cache
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html;charset=UTF-8

In the example above, the session cookie is JSESSIONID and the session ID is 71867A63768B13C9B58E623401BE7C57.tastcomapp01.

Subsequent HTTP requests include the session id as a header:

GET /thirdpartyheaderarray HTTP/1.1
Host: 10.58.128.48
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://10.58.128.48/
Cookie: JSESSIONID=71867A63768B13C9B58E623401BE7C57.tastcomapp01

Inexistent Server-Side Session

If the browser invocation contains a Cookie header with a session ID that does to exist on the server side, the call to HttpServletRequest.getSession(false) returns null.

The server-side code may choose to create a new session and send a new session ID with the Set-Cookie header. The browser will comply and replace the obsolete session ID.

Invalidating a Session

A session can be invalidated (destroyed) with the HttpSession.invalidateSession() API call. Upon invalidation, the session disappears from memory and the JSESSIONID cookies residing on browsers become obsolete. It is good practice to reset the invalid JSESSIONID cookie on invoking browser after invalidation. Am example of how to do that is presented below:

//
// remove JSESSIONID from browser
//

Cookie oldJSessionIdCookie = context.getCookie("JSESSIONID");
Cookie cookie = new Cookie(oldJSessionIdCookie.getName(), null);
cookie.setPath(oldJSessionIdCookie.getPath());
cookie.setMaxAge(0);
HttpServletResponse response = ...
response.addCookie(cookie);

Authentication and Session

Both unauthenticated users and authenticated users can maintain sessions.

Session Lifecycle

When a user first accesses a web application, that user is assigned a new javax.servlet.http.HttpSession object and a unique session ID. The session ID identifies the user and it is used to match the user with HttpSession object in subsequent requests. HttpSession provides a way to identify a user across more than one page request or visit to a Web site and to store information about that user. The servlet container uses this interface to create a session between an HTTP client and an HTTP server. The session persists for a specified time period, across more than one connection or page request from the user. A session usually corresponds to one user, who may visit a site many times.

Behind the scenes, the session ID is usually saved on the client in a cookie called JSESSIONID. For clients that don't support cookies, the session ID can be sent as part of a rewritten URL, encoded using a jsessionid parameter, e.g. http://server.com/servlet/MyServlet__;jsessionid=123__?item=1234. Other implementations using SSL are also possible.

The programmer can get the HttpSession associated with an user from inside the servlet using getSession() method.

The programmer then can save any set of arbitrary Java objects in a session object (the only limitation is that the saved objects must be Serializable). To add data to the session, use

public void HttpSession.setAttribute(String name, Object value)

To retrieve data from a session use

public Object HttpSession.getAttribute(String name)

JBossWeb/Tomcat HTTP Session Implementation Details

JBossWeb/Tomcat HTTP Session Implementation Details

Session Replication

HTTP Session Replication