In SpringBoot2.x version the pit stepped on by SpringSession and its solution

SpringBoot2.x SpringSession stepping on the pit

Exception encountered during context initialization-cancelling refresh attempt: org. springframework. beans. factory. BeanCreationException: Error creating bean with name 'org. springframework. boot. autoconfigure. session. SessionAutoConfiguration $ServletSessionRepositoryValidator': Invocation of method failed; nested exception is ES40springframework. EN could be auto-configured, check your configuration (session store type is 'redis')

This is due to the absence of the spring-session-data-redis dependency.

With regard to SpringBoot2. X, referencing SpringSession and using Redis to store cached data requires the following configuration:

 <!--SpringSession Dependency -->
 <dependency>
  <groupId>org.springframework.session</groupId>
  <artifactId>spring-session-core</artifactId>
 </dependency>
 <!--SpringSessionRedis Dependency -->
 <dependency>
  <groupId>org.springframework.session</groupId>
  <artifactId>spring-session-data-redis</artifactId>
 </dependency>

# Use use Redis Cache session Data 
spring.session.store-type=REDIS
#Redis Server address 
spring.redis.host=127.0.0.1
#Redis Server port number 
spring.redis.port=6379

Summary:

In the version of SpringBoot2.x, when referring to spring-session-core, it is not loading spring-session-data-redis, but the user needs to add the association dependency about spring-session and redis himself.

springboot 2. x stepping on the pit-cross-domain causes session problems

At present, the front and back ends of IT are separated, but there will be cross-domain problems in the process of separation.

What is cross-domain?

It means that when the browser requests the resources of another domain name from the web page of one domain name, the domain name, port and protocol are all cross-domain.

Scenes encountered

When we use springboot + shrio + vue to do the background management project, we can't get the current logged-in user of shiroSession.

So we checked, and the Internet said that it is ok to let session pass when crossing domains

Back end

@Configuration
public class CorsConfig {
    private CorsConfiguration buildConfig() {
        CorsConfiguration corsConfiguration = new CorsConfiguration();
        corsConfiguration.setAllowCredentials(true);
        //  Allow any domain name to use 
        corsConfiguration.addAllowedOrigin("*");
        //  Allow any header 
        corsConfiguration.addAllowedHeader("*");
        //  Allow any method ( post , get Etc.) 
        corsConfiguration.addAllowedMethod("*");
        corsConfiguration.setMaxAge(3600L);
        return corsConfiguration;
    }
    @Bean
    public CorsFilter corsFilter() {
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        //  Configure cross-domain settings for interfaces 
        source.registerCorsConfiguration("/**", buildConfig());
        return new CorsFilter(source);
    }
}

Front end

axios.defaults.withCredentials=true; 

But it still doesn't work after setting it up

After one day's Baidu and investigation, I rolled back to springboot 1. x and didn't have this problem, only to locate that it was the cause of upgrading to springboot 2. x. Well, the murderer has been caught, so it is good to prescribe the right medicine. I went online to see the problems related to upgrading springboot to 2. x spring session.

Finally discovered the New World, SameSite was introduced into Cookie in spring-session 2. x, and its default value is Lax. Ok, let's take a look at what this is.

SameSite Cookie is used to prevent CSRF attacks and has two values: Strict, Lax

SameSite = Strict：

Strict mode, indicating that this cookie cannot be used as a third party cookie under any circumstances;

SameSite = Lax：

It means loose mode. In GET request, it can be used as a third-party cookie, but it cannot carry cookie for cross-domain post access (this is very painful, our verification interface is POST request)

Summary: The front-end requests to the background, each session is not 1, each time is a new session, resulting in no access to user information

Solution:

Set SameSite to null

@Configuration
public class SpringSessionConfig { 
    @Bean
    public CookieSerializer httpSessionIdResolver() {
        DefaultCookieSerializer cookieSerializer = new DefaultCookieSerializer();
        //  Cancellation is limited to the same 1 Site Settings 
        cookieSerializer.setSameSite(null);
        return cookieSerializer;
    }
}

Problem solved! !