将 JEE Servlet HttpSession 存储在 Redis 中.zip

# HTTP Session Replacement [](https://search.maven.org/#search%7Cga%7C1%7Ccom.amadeus.session) [](http://www.javadoc.io/doc/com.amadeus/session-replacement) [](http://travis-ci.org/AmadeusITGroup/HttpSessionReplacer) [](LICENSE) [](https://www.versioneye.com/user/projects/583d2f19d2fd57003fdfbe76/) [](https://sonarqube.com/dashboard?id=com.amadeus%3Asession) [](https://sonarqube.com/dashboard?id=com.amadeus%3Asession) This project provides session management including, possibly, distributed session repository for JEE and other java containers. Default implementation comes with in-memory and Redis based implementation. The project is inspired by Spring Session project and reuses some of redis logic from it. Its objective is to avoid any dependency on Spring libraries, and, so, make it usable in applications that don't use Spring, or that use an older version. The implementation, however, uses the Jedis library directly. This makes the algorithm easier to port to other languages. The project aims to make session management transparent for existing webapps (zero code change) and as compatible as possible with wide variety of the JEE containers, all the while offering full support for session API including different session listeners. Redis support includes both single instance, sentinel based and cluster modes. Two session expiration strategies are available when using Redis. One is based on Redis notifications, and antoher on sorted sets (ZRANGE). Useful links: * For details about installing the library see [docs/Usage.md](docs/Usage.md) * For information about building this project see [docs/BUILD.md](docs/BUILD.md). * For information about using session encryption see [docs/ENCRYPTION.md](docs/ENCRYPTION.md). ## HTTP Servlet support The primary usecase is the support for session management for `HttpSessions`. Support includes the following: * Creation of sessions on demand * Storing of session attributes between requests * Invalidation of sessions * Session expiration management * Session propagation to clients via cookie and URL. * Full support for all non-deprecated `HttpSession` methods * Support for callbacks for values stored in session that implement `javax.servlet.http.HttpSessionActivationListener` or `javax.servlet.http.HttpSessionBindingListener` * When used with an agent, support for listener objects such as `javax.servlet.http.HttpSessionListener` and `javax.servlet.http.HttpSessionAttributeListener` * Support for Servlet 3.1 features such as session id switch * Compatibility with Servlet 2.5 * Session stickiness - sessions can be sticked to node and expiration events will then be triggered on node owner of session * Support for non-distributable web applications ### General Concepts #### Session Repository The session information needs to be stored between server request. This storage is called session repository. Different repository implementations are supported by the session replacement mechanism. #### Configuration Most of the configuration can be specified with `ServletContext`s initialization parameters, system properties and some paramaters can be provided via the agent. Unless otherwise specified the general rule for priority of configuration is as follows in descending order: * `ServletContext`s initiate parameters (set through `web.xml` or programmatically since Servlet 3.x ) * Agent configuration (when exists) * System properties * Default values #### Architecture Here is the block diagram of the architecture: ``` +--------------------------------------------------+ | | | +---+ +-------------------------------+ | | | | | | | | | | | | | | | * | | | | | | F | | | | | | I | Wrapped | WEB APPLICATION | | | | L | request | | | HTTP | | T |--------->| | | ---->| | E | | | | HTTPS| | R | | | | | | * | | | | | | | +-------------------------------+ | | | | ^ | | | | Session interaction | | | | | v | | | +------------------------------------------+ | | | *Session-management* | | | +----------------------------------------------+ | | Container (e.g. JBoss, jetty, tomcat) | +-------------------------------------+------------+ | JVM | *Agent* | +-------------------------------------+------------+ ``` In the above picture, *Agent*, *Filter* and *Session-management* are modules added to support session storage in repository. * The *Filter* wraps all incoming requests to allow session retrieval and commit. When using the agent, all filters have code to wrap incoming requests, however, only the first one will wrap it. The following filter in chain will return the request it received. The canonical implementation of a filter is [com.amadeus.session.servlet.SessionFilter](session-replacement/src/main/java/com/amadeus/session/servlet/SessionFilter.java) * The *Session-management* is intercepting all interactions with sessions and communicates with the session repository. Normally, unless using container specific interface, container should not be aware of the existence of the session. * The *Agent* performs instrumentation as described below. ### Session management The general algorithm for managing sessions is independent of the underlying storage. It has the following characteristics: * Session retrieval from repository. * New session creation of session with cryptographically secure session id. For details see Session id section. * Partial and full session updates allows updating all session attributes or only those that were changed or touched during session request (if repository supports it). For details see Optimized session updates section. * Support for atomic commit allows updating all attributes at once in one transaction or network exchange (if repository supports it). * Support of non-cacheable attributes, i.e. attributes that are stored or retrieved from repository on each access to session attribute. For details see Non-sticky sessions and concurrent access. * Support for session encryption when storing sessions into repository. #### Optimized session updates The session management keeps track of the attributes that have changed (including deletion) and only updates those. This means if an attribute is written once and read many times we only need to write that attribute once. Session management can be configured to update all the attributes no matter what or to update all non-primitive wrappers #### Session id A session id is an UUID generated using type 4 algorithm, a random sequence of bytes encoded in modified base64 algor