Engineering Full Stack Apps with Java and JavaScript
We have already seen basic session management in Java EE using cookies and URL rewriting. Now we will quickly see some of the remaining important topics such as SSL sessions, session life cycle, passivation and sessions in distributed applications.
Session Life Cycle
There are three stages in the life of a session
It is impossible for server to know if client has left the session or not and hence a session can never be terminated. This is because, unlike stateful protocols like FTP, HTTP is stateless. However server will maintain a session timeout and if there are no requests from the client for that entire timeout duration, the session will be invalidated.
A session timeout is defined through the deployment descriptor using session-timeout sub-element of session-config and the timeout is specified in minutes. If 0 or negative, sessions will never timeout. If element is omitted, java ee server can use its own values and average is usually around 30 minutes. There is no annotation alternative for this.
If client needs to request for a session to be invalidated, then server needs to provide an explicit method or means to do that like a logout link. Unlike stateful protocols like FTP, stateless protocols like HTTP do not have a close method. In case of a stateful protocol, if the client step away from communication, the connection is automatically and there is no need for an explicit request as in the case of stateless protocols.
SSL Sessions
TLS/SSL provides inherent connection tracking mechanism in its connection between the client and server. The container can use this mechanism to track the client when the client is using an SSL based protocol such as HTTPS (Secure HTTP). Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communications security over a computer network. They use X.509 certificates and hence asymmetric cryptography to authenticate the counterparty with whom they are communicating, and to exchange a symmetric key. This session key is then used to encrypt data flowing between the parties. In OSI model equivalences, TLS/SSL is initialized at layer 5 (session layer) and works at layer 6 (the presentation layer). The session layer has a handshake using an asymmetric cipher in order to establish cipher settings and a shared key for that session; then the presentation layer encrypts the rest of the communication using a symmetric cipher and that session key. We will see TSL/SSL and their session mechanism later in security notes.
Passivation
Passivation is the process of serializing a session. This may be done either to transport sessions over a network (Session Migration) or to save inactive objects with longer objects to persistent storage (HD) to save memory (RAM). Passivation is similar to operating system’s virtual memory where older RAM memory may be written to persistent storage (HD) to save memory (RAM).
Container can only interact with active object forms of a session. So when a request is made in an already passivated session, then the session needs to be read back into memory from its serialized form and activated again. There is a listener interface HttpSesssionActivationListener which can listen to the passivate and activate events.
Session migration is the transfer of session objects across web containers via serialization to handle requests in distributed applications where the request can come to any of the available servers. Therefore if sessions need to be migrated (or passivated), all objects added to an HttpSession as attributes, need to implement Serializable.
Session Listeners
There are five session related listeners:
HttpSessionListener
HttpSessionAttributeListener
HttpSessionBindingListener
HttpSesssionActivationListener
HttpSessionIdListener
You can read more about these listeners @ http://javajee.com/servlet-listeners-and-events.
References