从你提供的配置文件(应该是 Spring Boot 的 application.yml
或 application.properties
文件)来看,以下部分与会话超时时间相关:
server:
servlet:
session:
timeout: 12h
# timeout: 30
cookie:
name: VENDER_SID
会话超时时间的设置
server.servlet.session.timeout: 12h
:- 这行配置明确指定了 HTTP 会话的超时时间为 12 小时。
- 在 Spring Boot 中,
server.servlet.session.timeout
用于设置会话的最大不活动时间,单位可以是秒(默认)、分钟(m
)、小时(h
)等。 - 这里
12h
表示 12 小时,也就是 43,200 秒。
#timeout: 30
:- 这行被注释掉了。如果没有
12h
的配置,超时时间会是 30(可能是 30 分钟或 30 秒,取决于上下文,但通常默认单位是分钟)。但由于12h
生效,这行不起作用。
- 这行被注释掉了。如果没有
cookie.name: VENDER_SID
:- 这指定了会话的 cookie 名称为
VENDER_SID
,而不是默认的JSESSIONID
。客户端通过这个 cookie 跟踪会话。
- 这指定了会话的 cookie 名称为
与 ADMIN_ID
的关系
在你的代码中:
request.getSession().setAttribute(Constants.ADMIN_ID, admin.getId());
Constants.ADMIN_ID
被存储到会话中,它的生命周期与会话一致。- 根据配置文件,会话的超时时间是 12 小时。这意味着:
- 用户登录后,
ADMIN_ID
被写入会话。 - 如果用户在 12 小时内没有任何活动(即没有发送新的请求),会话会过期,
ADMIN_ID
会随之失效。 - 如果用户在这 12 小时内保持活跃(发送请求),会话会自动续期,
ADMIN_ID
会一直有效。
- 用户登录后,
其他相关配置的影响
server.tomcat.max-threads: 3000
:- 设置 Tomcat 的最大线程数为 3000,与会话超时无关,只是影响服务器的并发处理能力。
- 没有手动设置
setMaxInactiveInterval
:- 从配置文件来看,你没有在代码中手动调用
request.getSession().setMaxInactiveInterval()
,因此会话超时完全由server.servlet.session.timeout
控制。
- 从配置文件来看,你没有在代码中手动调用
总结
登录一次后
ADMIN_ID
的过期时间:- 根据你的配置,
ADMIN_ID
在会话中的过期时间是 12 小时(12h
)。 - 如果用户在 12 小时内没有活动,会话超时,
ADMIN_ID
失效。 - 如果用户持续活跃,会话不会过期,
ADMIN_ID
会一直保留,直到手动注销(例如调用session.invalidate()
)或服务器重启。
- 根据你的配置,
验证方法:
- 你可以在登录后打印会话的超时时间来确认:
应该输出System.out.println("Session timeout: " + request.getSession().getMaxInactiveInterval());
43200
(12 小时的秒数)。
- 你可以在登录后打印会话的超时时间来确认:
注意事项:
- 如果你的应用还依赖 JWT(从之前的
JwtUtils.createToken
看可能有),JWT 的过期时间可能是独立的,需要检查JwtUtils
的实现来确认 token 的生命周期。 - 如果需要调整超时时间,可以直接修改
timeout: 12h
为其他值,例如24h
或30m
。
- 如果你的应用还依赖 JWT(从之前的
这个配置回答了你的问题:ADMIN_ID
在登录后会存活 12 小时,除非用户活跃或手动注销。