如何设置浏览器在某个网站使用的JSESSIONID

JSESSIONID 是在进程中共享的Cookie,通常仅存储于内存，由Web Server 动态产生，用于跟踪浏览器用户的工作期

当然，Cookie就是Cookie,只以名值识别，你是放内存，还是硬盘，都没有区别，所以使用向硬盘中写Cookie文件的方式，只要指定的域有效，浏览器都会回传服务器

Cookie 除了 key 和 value 以外有几个属性。

其他的都很熟悉了，最后一个是 Chrome 51 开始，浏览器的 Cookie 新增加了一个 SameSite 属性，用来防止 CSRF 攻击和用户追踪。

在Javaweb应用中 ，设置 Cookie一般都是用 javax.servlet.http.Cookie ，但是 SameSite 属性出来不久， Servlet 库还没更新，所以没有设置 SameSite 的方法.

可以看到，还没有 SameSite 的定义

本质上， Cookie 也只是一个 header 。我们可以不使用 Cookie 对象，而通过自定义 Header 的方式来给客户端设置 Cookie 。

ResponseCookie 是Spring定义的一个 Cookie 构建工具类，极其简单

所有属性都响应正确 √

HttpSession 依赖一个名称叫做 JSESSIONID （默认名称）的Cookie。

对于 JSESSIONID Cookie 的设置，可以修改如下配置。但是，目前spring也没实现 SameSite 的配置项。

通过自定义 CookieSerializer 设置 SameSite 属性

原文： https://springboot.io/t/topic/2602

注：以下内容基于以tomcat作为web服务器

session是http协议无状态问题的常见解决方案之一 ，用户登录成功之后，把用户信息保存到session（默认储存在服务端的内存）。对于浏览器发起的HTTP请求，可以根据session中是否存在用户信息判断用户是否登录，也方便业务逻辑中获取当前会话用户信息。

服务端创建session时，会生成JSESSIONID作为唯一标识，并将一个key为"JSESSIONID"的cookie返回给前端（前提是浏览器支持cookie），之后，根据浏览器发起请求时携带的JSESSIONID判断用户身份。

tomcat的JSESSIONID生成的机制是一个随机数加时间加上jvm的id值，jvm的id值会根据服务器的硬件信息计算得来，因此不同jvm的id值都是唯一的。

当后端显式调用request.getSession()或request.getSession(true)时，会创建session（注意：需要显式调用，spring或tomcat不会自动生成）

request.getSession()有个重载方法request.getSession(boolean create)

create为true表示，若可以根据前端cookie中的JSESSIONID找到对应的session，则返回该session，否则重新创建一个session，并把新的JSESSIONID返回给前端。

create为false表示，若可以根据前端cookie中的JSESSIONID找到对应的session，则返回该session，否则返回null。

request.getSession()等价于request.getSession(true)

session是http协议无状态问题的常见解决方案之一，但在用户量大，或者分布式系统等场景下，该方案有许多弊端。

1.session默认储存在服务端内存，用户量大时占用内存多

2.需要处理session共享，用户在一台服务器登录后，集群内其他机器没有该用户的session，需要用某些方式实现session共享，并保持一致性，即同步修改所有机器的session

3.同样的数据保存在多台服务器，数据冗余

4.如果使用cookie发送JSESSIONID到服务端，则不支持跨域请求

5.如果浏览器cookie被禁用，就需要用其余方式保存JSESSIONID

6.如果session没有持久化，重启服务器后session就没了

修改负载均衡策略为按ip负载（即同一个ip只访问同一台机器），这样就绕开了session共享的问题（默认策略一般是轮询）

弊端

按ip负载策略和轮询策略，本质上是按用户负载和按请求负载，这两种策略的区别在于， 按请求负载更加均衡 ，比如A、B服务器都有20个用户，A服务器的20个用户相比B服务器更加活跃，那么A服务器的压力就更大。

集成spring-session-redis（网上很多教程），先集成redis，然后在启动类加上@EnableRedisHttpSession注解，这样 *** 作session时，会自动把数据持久化到redis集群

tomcat 配置session复制（未做了解）

同时使用token+session，token用于接口鉴权，session用于保存用户信息。

增加一个拦截器，在找不到session时，根据token反解析出用户信息，然后存入session。

（一般公司会有统一的用户中心，提供校验token并返回用户身份的接口）

严格来说，本方案不算是session共享方案，因为不同服务端的session id不一致，每次请求不同服务器，带上来的session id在本服务器找不到，就产生新的session，直到有效期到期才销毁，严重浪费内存

1.最常见的方式: cookie

2.如果cookie被禁止，可以用URL重写技术，把session id拼接到URL中

3.在表单添加隐藏字段，提交表单时把session id传到服务端

先说结论：如果服务器是集群，且没有配置会话保持，同一个浏览器窗口的JSESSIONID就会变化

用户在A服务器登录成功后，A服务器把key为JSESSIONID的cookie返回给用户，然后携带该JSESSIONID请求B服务器，B服务器找不到该JSESSIONID对应的session，就会创建新的session，把新的JSESSIONID返回给用户。

取决于JSESSIONID的保存方式

如果保存在cookie，要看cookie有没有设置有效期，如果没设有效期，重启浏览器cookie就没了，如果设了有效期，重启浏览器cookie还在。

如果使用URL重写或表单隐藏字段的方式，要看JSESSION具体保存在哪

对于单机应用，JSESSIONID可以用于校验接口（类似于token），后端如果能根据JSESSIONID获取到对应session（即request.getSession(false)不为空），说明该请求有效。但是服务器一旦重启，用户登录就失效了，因为session放在内存中。

如果使用token做接口校验，不仅可以适用于分布式应用，后端重启也不会影响用户的登录态。

---