You signed in with another tab or window.
Reload
to refresh your session.
You signed out in another tab or window.
Reload
to refresh your session.
You switched accounts on another tab or window.
Reload
to refresh your session.
By clicking “Sign up for GitHub”, you agree to our
terms of service
and
privacy statement
. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
I have login module using spring-security and spring-session-data-redis.
In springboot 1.5.x, I use annotation @EnableRedisHttpSession(maxInactiveIntervalInSeconds = 43200) to set timeout 12 hours, I am very sure it's worked on production environment.
When I upgrade to springboot 2.x.x, following document set server.servlet.session.timeout=PT12H on application.properties and remove maxInactiveIntervalInSeconds(I am not sure it's necessary).
one day my engineer and tester told me timeout maybe not work(because 12 hours is too long), so I set PT60S to test it.
flushall on redis-cli
login
check spring:session:expirations
because my time zone is GTM+8, so 2019/2/21 21:30:0 - 22 Jan 2019 13:29:40 - 8:00:00 = 30 days
By using
@EnableRedisHttpSession
you are telling Spring Boot that you want to take complete control over the configuration of Redis-based HTTP sessions. As a result, its auto-configuration backs off and
server.servlet.session.timeout
has no effect. If you want to use
server.servlet.session.timeout
then you should remove
@EnableRedisHttpSession
. Alternatively, if you want to use
@EnableRedisHttpSession
then you should use the
maxInactiveIntervalInSeconds
attribute to configure the session timeout.
lvzhihao, nellymin, ade951, 9526xu, Zalimben, wangcheng34, samhonarvar, and KunChengNHS reacted with thumbs up emoji
9526xu and rs-dshinde reacted with rocket emoji
All reactions
@olayinkasf
This is an example of Spring Boot auto-configuration
backing away
when you start configuring things yourself.
What do you mean by "a managed session"?
What could we do to make it clearer? It's standard Spring Boot behaviour for things that are auto-configured to switch off when you start configuring things yourself. The documentation mentions running with
--debug
to learn about the auto-configuration that is being applied and why. If you happened to try that, did it help at all?
@wilkinsona
, as I've seen similar confusion in Spring Session's issue tracker and on Stack Overflow already, I do believe Spring Boot's reference manual could be a bit more explicit about the auto-config vs native configuration support.
For instance, the section that covers
Spring HATEOAS auto-config
clearly states that:
The auto-configuration replaces the need to use
@EnableHypermediaSupport
...
As well as:
You can take control of Spring HATEOAS’s configuration by using
@EnableHypermediaSupport
.
At the same time the section that covers
Spring Session auto-config
has not mention of
@Enable*HttpSession
/
@Enable*WebSession
. A sentence or two mentioning these in a manner similar to HATEOAS section would be very helpful in avoiding the kind of confusion we're seeing here.
Hi, I don't want to revive this issue again, but I had this problem for multiple versions of Spring Boot 2.3.x (currently on 2.3.4).
I have this in my application.properties:
server.servlet.session.cookie.http-only=true
server.servlet.session.cookie.secure=true
server.servlet.session.cookie.max-age=-1
server.servlet.session.cookie.name=SESSION
server.servlet.session.timeout=14400s
#server.session.timeout=14400s # tried to uncomment this, just to be sure, but nothing changed
spring.session.store-type=redis
spring.data.redis.repositories.enabled = false
spring.redis.host=redis
spring.redis.port=6379
The app completely ignores these properties and all redis sessions are created with TTL around 1800 seconds.
I don't use EnableRedisHttpSession or EnableJdbcHttpSession or anything session related.
Only thing I use are these:
@SpringBootApplication(scanBasePackages = ["app"])
@EnableHypermediaSupport(type = [EnableHypermediaSupport.HypermediaType.HAL])
@EnableScheduling
@EnableWebSecurity
class BackendApplication
@Configuration
class SecurityConfig : WebSecurityConfigurerAdapter() {
public override fun configure(http: HttpSecurity) {
http.csrf().disable()
.cors()
.and()
.exceptionHandling()
.authenticationEntryPoint(restAuthenticationEntryPoint)
.and()
.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED).and() // .httpBasic().realmName("AD").and()
.httpBasic().disable() // we use our own implementation for HttpBasic
.formLogin().loginProcessingUrl("/login").and()
.logout().logoutUrl("/logout").logoutSuccessHandler(HttpStatusReturningLogoutSuccessHandler(HttpStatus.NO_CONTENT)).permitAll().and()
.addFilter(CustomBasicAuthenticationFilter(authenticationManager(), userService))
.addFilterAt(RestAuthenticationFilter(authenticationManager(), userService), UsernamePasswordAuthenticationFilter::class.java)
.authorizeRequests()
.antMatchers("/login").permitAll()
.antMatchers("/actuator/info").permitAll()
.antMatchers("/actuator/health").permitAll()
.antMatchers("/actuator/**").hasRole("ADMIN")
.anyRequest().authenticated()
Only if I add @EnableRedisHttpSession(maxInactiveIntervalInSeconds = 14400)
, then and only then the records in redis have correct TTL.
I couldn't find anything relevant in --debug output (but I don't know what I should be looking for).
What could be the problem in my case? Could it be the WebSecurityConfigurerAdapter stuff?
EDIT: I've tried removing all @EnableXYZ annotations from the code, but no change, TTL is still around 1800s.
@daliborfilus Can you please open a new issue with a small sample that reproduces the problem? In the absence of spring.session.timeout
being set, server.servlet.session.timeout
should be used to auto-configure Spring Session's session timeout. Your WebSecurityConfigurerAdapter
shouldn't have any effect on that.
So I was creating the example app with smallest possible reproducible case and I've nailed the problem down to this line in my build.gradle config:
configurations {
compile.exclude group: 'jakarta.annotation', module: 'jakarta.annotation-api' // <<- THIS ONE
If I remove it (or comment it out), the server.servlet.session.timeout=14400s line in application.properties works.(Tested using redis-cli monitor
multiple times).
I remember excluding this group when I played with java jigsaw modules and it something was complaining about the same interfaces being implemented in more than one package or something like that.
Should I still create a new issue? I still don't understand why excluding jakarta.annotation group would result in such weird behavior. The application works with this for over a year and the only thing that doesn't work correctly is this redis session timeout thing...
server.servlet.session.timeout not in effect when using Jetty starter without jakarta.annotation and javax.annotation
#23716