• 欢迎访问 winrains 的个人网站!
  • 本网站主要从互联网整理和收集了与Java、网络安全、Linux等技术相关的文章,供学习和研究使用。如有侵权,请留言告知,谢谢!

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

Session winrains 来源:GuoLei Song 6个月前 (03-21) 34次浏览

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

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

sessionId 解析策略

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

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

HttpSessionIdResolver

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

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

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

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

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

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

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 类的实现如下:

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值的响应头。

// 使用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的逻辑,细节在代码中通过注释标注出来。

@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里面去,最终再浏览器中显示大体如下:

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

jvm_router的处理

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

1、读取Cookie中的代码片段

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

2、回写Cookie中的代码片段

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/


版权声明:文末如注明作者和来源,则表示本文系转载,版权为原作者所有 | 本文如有侵权,请及时联系,承诺在收到消息后第一时间删除 | 如转载本文,请注明原文链接。
喜欢 (2)