glmapper

SpringSession系列-sessionId解析和Cookie读写策略

字数统计: 2.1k阅读时长: 8 min
2018/12/23 Share

首先需求在这里说明下,SpringSession的版本迭代的过程中肯定会伴随着一些类的移除和一些类的加入,目前本系列使用的版本是github上对象的master的代码流版本。如果有同学对其他版本中的一些类或者处理有疑惑,欢迎交流。

本篇将来介绍下SpringSession中两种sessionId解析的策略,这个在之前的文章中其实是有提到过的,这里再拿出来和SpringSessionCookie相关策略一起学习下。

sessionId 解析策略

SpringSession中对于sessionId的解析相关的策略是通过HttpSessionIdResolver这个接口来体现的。HttpSessionIdResolver有两个实现类:
在这里插入图片描述

这两个类就分别对应SpringSession解析sessionId的两种不同的实现策略。再深入了解不同策略的实现细节之前,先来看下HttpSessionIdResolver接口定义的一些行为有哪些。

HttpSessionIdResolver

HttpSessionIdResolver定义了sessionId解析策略的契约(Contract)。允许通过请求解析sessionId,并通过响应发送sessionId或终止会话。接口定义如下:

1
2
3
4
5
public interface HttpSessionIdResolver {
List<String> resolveSessionIds(HttpServletRequest request);
void setSessionId(HttpServletRequest request, HttpServletResponse response,String sessionId);
void expireSession(HttpServletRequest request, HttpServletResponse response);
}

HttpSessionIdResolver中有三个方法:

  • resolveSessionIds:解析与当前请求相关联的sessionIdsessionId可能来自Cookie或请求头。
  • setSessionId:将给定的sessionId发送给客户端。这个方法是在创建一个新session时被调用,并告知客户端新sessionId是什么。
  • expireSession:指示客户端结束当前session。当session无效时调用此方法,并应通知客户端sessionId不再有效。比如,它可能删除一个包含sessionIdCookie,或者设置一个HTTP响应头,其值为空就表示客户端不再提交sessionId

下面就针对上面提到的两种策略来进行详细的分析。

基于Cookie解析sessionId

这种策略对应的实现类是CookieHttpSessionIdResolver,通过从Cookie中获取session;具体来说,这个实现将允许使用CookieHttpSessionIdResolver#setCookieSerializer(CookieSerializer)指定Cookie序列化策略。默认的Cookie名称是“SESSION”。创建一个session时,HTTP响应中将会携带一个指定 Cookie namevaluesessionIdCookieCookie 将被标记为一个 session cookieCookiedomain path 使用 context path,且被标记为HttpOnly,如果HttpServletRequest#isSecure()返回true,那么Cookie将标记为安全的。如下:

关于Cookie,可以参考:聊一聊session和cookie

1
2
HTTP/1.1 200 OK
Set-Cookie: SESSION=f81d4fae-7dec-11d0-a765-00a0c91e6bf6; Path=/context-root; Secure; HttpOnly

这个时候,客户端应该通过在每个请求中指定相同的Cookie来包含session信息。例如:

1
2
3
GET /messages/ HTTP/1.1
Host: example.com
Cookie: SESSION=f81d4fae-7dec-11d0-a765-00a0c91e6bf6

当会话无效时,服务器将发送过期的HTTP响应Cookie,例如:

1
2
HTTP/1.1 200 OK
Set-Cookie: SESSION=f81d4fae-7dec-11d0-a765-00a0c91e6bf6; Expires=Thur, 1 Jan 1970 00:00:00 GMT; Secure; HttpOnly

CookieHttpSessionIdResolver 类的实现如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
public final class CookieHttpSessionIdResolver implements HttpSessionIdResolver {
private static final String WRITTEN_SESSION_ID_ATTR = CookieHttpSessionIdResolver.class
.getName().concat(".WRITTEN_SESSION_ID_ATTR");
// Cookie序列化策略,默认是 DefaultCookieSerializer
private CookieSerializer cookieSerializer = new DefaultCookieSerializer();

@Override
public List<String> resolveSessionIds(HttpServletRequest request) {
// 根据提供的cookieSerializer从请求中获取sessionId
return this.cookieSerializer.readCookieValues(request);
}

@Override
public void setSessionId(HttpServletRequest request, HttpServletResponse response,
String sessionId) {
if (sessionId.equals(request.getAttribute(WRITTEN_SESSION_ID_ATTR))) {
return;
}
request.setAttribute(WRITTEN_SESSION_ID_ATTR, sessionId);
// 根据提供的cookieSerializer将sessionId回写到cookie中
this.cookieSerializer
.writeCookieValue(new CookieValue(request, response, sessionId));
}

@Override
public void expireSession(HttpServletRequest request, HttpServletResponse response) {
// 这里因为是过期,所以回写的sessionId的值是“”,当请求下次进来时,就会取不到sessionId,也就意味着当前会话失效了
this.cookieSerializer.writeCookieValue(new CookieValue(request, response, ""));
}

// 指定Cookie序列化的方式
public void setCookieSerializer(CookieSerializer cookieSerializer) {
if (cookieSerializer == null) {
throw new IllegalArgumentException("cookieSerializer cannot be null");
}
this.cookieSerializer = cookieSerializer;
}
}

这里可以看到CookieHttpSessionIdResolver 中的读取操作都是围绕CookieSerializer来完成的。CookieSerializerSpringSession中对于Cookie操作提供的一种机制。下面细说。

基于请求头解析sessionId

这种策略对应的实现类是HeaderHttpSessionIdResolver,通过从请求头header中解析出sessionId。具体地说,这个实现将允许使用HeaderHttpSessionIdResolver(String)来指定头名称。还可以使用便利的工厂方法来创建使用公共头名称(例如“X-Auth-Token”“authenticing-info”)的实例。创建会话时,HTTP响应将具有指定名称和sessionId值的响应头。

1
2
3
4
5
6
7
8
// 使用X-Auth-Token作为headerName
public static HeaderHttpSessionIdResolver xAuthToken() {
return new HeaderHttpSessionIdResolver(HEADER_X_AUTH_TOKEN);
}
// 使用Authentication-Info作为headerName
public static HeaderHttpSessionIdResolver authenticationInfo() {
return new HeaderHttpSessionIdResolver(HEADER_AUTHENTICATION_INFO);
}

HeaderHttpSessionIdResolver在处理sessionId上相比较于CookieHttpSessionIdResolver来说简单很多。就是围绕request.getHeader(String)request.setHeader(String,String)
两个方法来玩的。

HeaderHttpSessionIdResolver这种策略通常会在无线端来使用,以弥补对于无Cookie场景的支持。

Cookie 序列化策略

基于Cookie解析sessionId的实现类CookieHttpSessionIdResolver 中实际对于Cookie的读写操作都是通过CookieSerializer来完成的。SpringSession 提供了CookieSerializer接口的默认实现DefaultCookieSerializer,当然在实际应用中,我们也可以自己实现这个接口,然后通过CookieHttpSessionIdResolver#setCookieSerializer(CookieSerializer)方法来指定我们自己的实现方式。

PS:不得不说,强大的用户扩展能力真的是Spring家族的优良家风。

篇幅有限,这里就只看下两个点:

  • CookieValue 存在的意义是什么
  • DefaultCookieSerializer回写Cookie的的具体实现,读CookieSpringSession系列-请求与响应重写 这篇文章中有介绍过,这里不再赘述。
  • jvm_router的处理

CookieValue

CookieValueCookieSerializer中的内部类,封装了向HttpServletResponse写入所需的所有信息。其实CookieValue的存在并没有什么特殊的意义,个人觉得作者一开始只是想通过CookieValue的封装来简化回写cookie链路中的参数传递的问题,但是实际上貌似并没有什么减少多少工作量。

Cookie 回写我觉得对于分布式session的实现来说是必不可少的;基于标准servlet实现的HttpSession,我们在使用时实际上是不用关心回写cookie这个事情的,因为servlet容器都已经做了。但是对于分布式session来说,由于重写了response,所以需要在返回response时需要将当前session信息通过cookie的方式塞到response中返回给客户端-这就是Cookie回写。下面是DefaultCookieSerializer中回写Cookie的逻辑,细节在代码中通过注释标注出来。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
@Override
public void writeCookieValue(CookieValue cookieValue) {
HttpServletRequest request = cookieValue.getRequest();
HttpServletResponse response = cookieValue.getResponse();
StringBuilder sb = new StringBuilder();
sb.append(this.cookieName).append('=');
String value = getValue(cookieValue);
if (value != null && value.length() > 0) {
validateValue(value);
sb.append(value);
}
int maxAge = getMaxAge(cookieValue);
if (maxAge > -1) {
sb.append("; Max-Age=").append(cookieValue.getCookieMaxAge());
OffsetDateTime expires = (maxAge != 0)
? OffsetDateTime.now().plusSeconds(maxAge)
: Instant.EPOCH.atOffset(ZoneOffset.UTC);
sb.append("; Expires=")
.append(expires.format(DateTimeFormatter.RFC_1123_DATE_TIME));
}
String domain = getDomainName(request);
if (domain != null && domain.length() > 0) {
validateDomain(domain);
sb.append("; Domain=").append(domain);
}
String path = getCookiePath(request);
if (path != null && path.length() > 0) {
validatePath(path);
sb.append("; Path=").append(path);
}
if (isSecureCookie(request)) {
sb.append("; Secure");
}
if (this.useHttpOnlyCookie) {
sb.append("; HttpOnly");
}
if (this.sameSite != null) {
sb.append("; SameSite=").append(this.sameSite);
}

response.addHeader("Set-Cookie", sb.toString());
}

这上面就是拼凑字符串,然后塞到Header里面去,最终再浏览器中显示大体如下:

1
Set-Cookie: SESSION=f81d4fae-7dec-11d0-a765-00a0c91e6bf6; Path=/context-root; Secure; HttpOnly

jvm_router的处理

Cookie的读写代码中都涉及到对于jvmRoute这个属性的判断及对应的处理逻辑。

1、读取Cookie中的代码片段

1
2
3
4
if (this.jvmRoute != null && sessionId.endsWith(this.jvmRoute)) {
sessionId = sessionId.substring(0,
sessionId.length() - this.jvmRoute.length());
}

2、回写Cookie中的代码片段

1
2
3
if (this.jvmRoute != null) {
actualCookieValue = requestedCookieValue + this.jvmRoute;
}

jvm_routeNginx中的一个模块,其作用是通过session cookie的方式来获取session粘性。如果在cookieurl中并没有session,则这只是个简单的 round-robin 负载均衡。其具体过程分为以下几步:

  • 1.第一个请求过来,没有带session信息,jvm_route就根据round robin策略发到一台tomcat上面。
  • 2.tomcat添加上 session 信息,并返回给客户。
  • 3.用户再次请求,jvm_route看到session中有后端服务器的名称,它就把请求转到对应的服务器上。

从本质上来说,jvm_route也是解决session共享的一种解决方式。这种和 SpringSession系列-分布式Session实现方案 中提到的基于IP-HASH的方式有点类似。那么同样,这里存在的问题是无法解决宕机后session数据转移的问题,既宕机就丢失。

DefaultCookieSerializer 中除了Cookie的读写之后,还有一些细节也值得关注下,比如对Cookie中值的验证、remember-me的实现等。

参考

原文作者:GuoLei Song

原文链接:http://www.glmapper.com/2018/12/23/spring-session-idresolver/

发表日期:December 23rd 2018, 12:10:59 am

更新日期:December 14th 2019, 11:00:37 am

版权声明:转载请注明出处

CATALOG
  1. 1. sessionId 解析策略
    1. 1.1. HttpSessionIdResolver
    2. 1.2. 基于Cookie解析sessionId
    3. 1.3. 基于请求头解析sessionId
  2. 2. Cookie 序列化策略
    1. 2.1. CookieValue
    2. 2.2. Cookie 回写
    3. 2.3. jvm_router的处理
  3. 3. 参考