Learn Spring Session and Redis to solve distributed Session cross-domain sharing issues

Use Spring Session and Redis to solve the problem of distributed Session cross-domain sharing

Explanation of the phenomenon:

The front-end and back-end codes in the project are not After separation, when the service is running normally on two instances, a prompt similar to the need to log in again will pop up occasionally, and the background error message

is a processor exception. The reason is not obvious.

After adding a machine instance, when accessing the front-end page, the login page is repeatedly accessed, resulting in page 302. Various signs indicate that it is caused by login configuration issues.

Related topic recommendations: php session (including pictures, texts, videos, cases)

Problem introduction : Session cannot be shared, resulting in polling between different machines requiring login, resulting in final service exception

Solution: Use Spring Session and Redis to solve the problem of distributed Session cross-domain sharing

Solution to configuration:

1 )Add dependency

<dependency>
  <groupId>org.springframework.session</groupId>
  <artifactId>spring-session-data-redis</artifactId>
  <version>1.2.0.RELEASE</version>
</dependency>
<dependency>
  <groupId>org.apache.velocity</groupId>
  <artifactId>velocity</artifactId>
  <version>1.7</version>
</dependency>

2 )Add web.xml configuration file:

<!-- 分布式Session共享Filter -->
<filter>
  <filter-name>springSessionRepositoryFilter</filter-name>
  <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
  <filter-name>springSessionRepositoryFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

3) Spring.xml configuration

<!-- 将session放入redis -->
<context:annotation-config/>
<bean id="redisHttpSessionConfiguration"   class="org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration">
   <property name="maxInactiveIntervalInSeconds" value="120" />
</bean>
<bean class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory">
   <!-- redis 配置 -->
   <property name="hostName" value="192.168.0.48" />
   <property name="port" value="6379" />
</bean>

Analysis:

1. DelegatingFilterProxy class in web: It belongs to the proxy fiter, which will start loading after tomcat starts. When filtering in web.xml, the management of the filter is handed over to the beans in spring. That is, the third step of the configuration introduces RedisHttpSessionConfiguration

2. RedisHttpSessionConfiguration inherits the SpringHttpSessionConfiguration class. This class is very important. SpringHttpSessionConfiguration passes @Bean Inject springSessionRepositoryFilter into the container

##3,

SessionRepositoryFilterThis filter is the filter searched for by DelegatingFilterProxy. The SessionRepositoryFilter is the key. How is it related?

If the init-param parameter is not specified, DelegatingFilterProxy will use filter-name as the Bean object to be found. This is also the role of the DelegatingFilterProxy class. It can be seen that every request will pass through this filter, and requests that pass through this filter will also pass through the springSessionRepositoryFilter filter, so let's take a look at

springSessionRepositoryFilterThis filter

4. The function of

SessionRepositoryFilter is to replace the container's default javax.servlet.http.HttpSession support to org.springframework.session.Session. The main methods and properties of

SessionRepositoryFilter are as follows:

##5. Among them,

SessionRepositoryResponseWrapper

, SessionRepositoryRequestWrapper, HttpSessionWrapper is an internal class, which is also very critical. For example, the SessionRepositoryRequestWrapper class

It can be seen that the SessionRepositoryRequestWrapper inherits the javax.servlet.http.HttpServletRequestWrapper class. We know that the default implementation of the HttpServletRequest interface is HttpServletRequestWrapper, as follows

6. Because SessionRepositoryRequestWrapper inherits HttpServletRequestWrapper, and HttpServletRequestWrapper implements the HttpServletRequest interface. In SessionRepositoryRequestWrapper, it rewrites some methods in the HttpServletRequest interface, so there are: getSession, changeSessionId, etc. method. At this point, we should roughly understand that the original request and response have been repackaged. We also understand how the original HttpSeesion was replaced by Spring Session.

We use the shortcut keys to view the specific implementation of request.getSession(), and we can see that there is already a method overridden by SessionRepositoryRequestWrapper. There are two default implementations above, one is original and the other is implemented by Spring Session. Which one should be selected as the implementation? This is the role of the DelegatingFilterProxy proxy we mentioned above. It will filter each request through DelegatingFilterProxy Each request will also go through the springSessionRepositoryFilter filter. The springSessionRepositoryFilter filter realizes the conversion of the original request to the SessionRepositoryRequestWrapper. This is the specific process!

request.getSession().setAttribute(name, value)Implementation: Tracking the code, you can reach the content below

You can see that there are Redis related operate! At this point, we should know how Spring Session works! Although the process below is not introduced again, it is already clearly understood.

Related learning recommendations: redis video tutorial

The above is the detailed content of Learn Spring Session and Redis to solve distributed Session cross-domain sharing issues. For more information, please follow other related articles on the PHP Chinese website!