Cookie、sessionStorage和localStorage

1. 共同点

都是保存在浏览器端，并且是同源的

2. 区别

2.1 生命周期

Cookie：可设置失效时间，否则默认为关闭浏览器后失效

Localstorage：除非被手动清除，否则永久保存

Sessionstorage：仅在当前网页会话下有效，关闭页面或浏览器后就会被清除

2.2 存放数据

Cookie：4k 左右

Localstorage 和 sessionstorage：可以保存5M 的信息

2.3 http 请求

Cookie：每次都会携带在 http 头中，如果使用 cookie 保存过多数据会带来性能问题

Localstorage 和 sessionstorage：仅在客户端即浏览器中保存，不参与和服务器的通信

2.4 易用性

Cookie：需要程序员自己封装，原生的 cookie 接口不友好

Localstorage 和 sessionstorage：即可采用原生接口，亦可再次封装

2.5 应用场景

从安全性来说，因为每次 http 请求都回携带 cookie 信息，这样子浪费了带宽，所以 cookie应该尽可能的少用，此外 cookie 还需要指定作用域，不可以跨域调用，限制很多，但是用户识别用户登陆来说，cookie 还是比storage 好用，其他情况下可以用 storage。localstorage 可以用来在页面传递参数，sessionstorage 可以用来保存一些临时的数据，防止用户刷新页面后丢失了一些参数。

补充说明一下 Cookie的作用：

保存用户登录状态。例如将用户 id 存储于一个 cookie 内，这样当用户下次访问该页面时就不需要重新登录了，现在很多论坛和社区都提供这样的功能。cookie 还可以设置过期时间，当超过时间期限后，cookie 就会自动消失。因此，系统往往可以提示用户保持登录状态的时间：常见选项有一个月、三个月、一年等。

跟踪用户行为。例如一个天气预报网站，能够根据用户选择的地区显示当地的天气情况。如果每次都需要选择所在地是烦琐的，当利用了 cookie 后就会显得很人性化了，系统能够记住上一次访问的地区，当下次再打开该页面时，它就会自动显示上次用户所在地区的天气情况。因为一切都是在后台完成，所以这样的页面就像为某个用户所定制的一样，使用起来非常方便定制页面。如果网站提供了换肤或更换布局的功能，那么可以使用 cookie 来记录用户的选项，例如：背景色、分辨率等。当用户下次访问时，仍然可以保存上一次访问的界面风格。

3. Cookie有哪些属性

3.1 Expires、Max Age

Expires选项用来设置“cookie 什么时间内有效”。Expires其实是cookie失效日期，Expires必须是 GMT 格式的时间（可以通过 new Date().toGMTString()或者 new Date().toUTCString() 来获得）。

如expires=Sat, 08 Sep 2018 02:26:00 GMT表示cookie将在2018年9月8日2:26分之后失效。对于失效的cookie浏览器会清空。如果没有设置该选项，这样的cookie称为会话cookie。它存在内存中，当会话结束，也就是浏览器关闭时，cookie消失。

补充：

Expires是 http/1.0协议中的选项，在http/1.1协议中Expires已经由 Max age 选项代替，两者的作用都是限制cookie 的有效时间。Expires的值是一个时间点（cookie失效时刻= Expires），而Max age的值是一个以秒为单位时间段（cookie失效时刻= 创建时刻+ Max age）。另外， Max age的默认值是 -1(即有效期为 session )； Max age有三种可能值：负数、0、正数。负数：有效期session；0：删除cookie；正数：有效期为创建时刻+ Max age

3.2 Domain和Path

Domain是域名，Path是路径，两者加起来就构成了 URL，Domain和Path一起来限制 cookie 能被哪些 URL 访问。即请求的URL是Domain或其子域、且URL的路径是Path或子路径，则都可以访问该cookie，例如：

某cookie的 Domain为“baidu.com”, Path为“/ ”，若请求的URL(URL 可以是js/html/img/css资源请求，但不包括 XHR 请求)的域名是“baidu.com”或其子域如“api.baidu.com”、“dev.api.baidu.com”，且 URL 的路径是“/ ”或子路径“/home”、“/home/login”，则都可以访问该cookie。

补充：

发生跨域xhr请求时，即使请求URL的域名和路径都满足 cookie 的 Domain和Path，默认情况下cookie也不会自动被添加到请求头部中。

3.3 Size

Cookie的大小

3.4 Secure

Secure选项用来设置cookie只在确保安全的请求中才会发送。当请求是HTTPS或者其他安全协议时，包含 Secure选项的 cookie 才能被发送至服务器。

默认情况下，cookie不会带Secure选项(即为空)。所以默认情况下，不管是HTTPS协议还是HTTP协议的请求，cookie 都会被发送至服务端。但要注意一点，Secure选项只是限定了在安全情况下才可以传输给服务端，但并不代表你不能看到这个 cookie。

补充：

如果想在客户端即网页中通过 js 去设置Secure类型的 cookie，必须保证网页是https协议的。在http协议的网页中是无法设置secure类型cookie的。

3.5 httpOnly

这个选项用来设置cookie是否能通过 js 去访问。默认情况下，cookie不会带httpOnly选项(即为空)，所以默认情况下，客户端是可以通过js代码去访问（包括读取、修改、删除等）这个cookie的。当cookie带httpOnly选项时，客户端则无法通过js代码去访问（包括读取、修改、删除等）这个cookie。

在客户端是不能通过js代码去设置一个httpOnly类型的cookie的，这种类型的cookie只能通过服务端来设置。

只要是httponly类型的,在控制台通过document.cookie是获取不到的，也不能进行修改。

之所以限制客户端去访问cookie，主要还是出于安全的目的。因为如果任何 cookie 都能被客户端通过document.cookie获取，那么假如合法用户的网页受到了XSS攻击，有一段恶意的script脚本插到了网页中，这个script脚本，通过document.cookie读取了用户身份验证相关的 cookie，那么只要原样转发cookie，就可以达到目的了。

3.6 SameSite

参考：https://www.ruanyifeng.com/blog/2019/09/cookie-samesite.html

Chrome 51 开始，浏览器的 Cookie 新增加了一个SameSite属性，用来防止 CSRF 攻击和用户追踪。

Cookie 的SameSite属性用来限制第三方 Cookie，从而减少安全风险。

它可以设置三个值。

Strict
Lax
None

（1）Strict

Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL 与请求目标一致，才会带上 Cookie。

Set-Cookie: CookieName=CookieValue; SameSite=Strict;

这个规则过于严格，可能造成非常不好的用户体验。比如，当前网页有一个 GitHub 链接，用户点击跳转就不会带有 GitHub 的 Cookie，跳转过去总是未登陆状态。

（2）Lax

Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。

Set-Cookie: CookieName=CookieValue; SameSite=Lax;

（3）None

Chrome 计划将Lax变为默认设置。这时，网站可以选择显式关闭SameSite属性，将其设为None。不过，前提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。

下面的设置无效。

Set-Cookie: widget_session=abc123; SameSite=None

下面的设置有效。

Set-Cookie: widget_session=abc123; SameSite=None; Secure

4. Cookie跨域共享

4.1 问题描述

参考：https://www.jianshu.com/p/9dbf09991479

需要解决前端跟服务端，跨域后都能获取到同一个cookie。

使用二级域名共享cookie有一个限制条件，就是两个域名的二级域名必须相同

前端pc访问域名：a.b.com

后端接口域名：a-gateway.b.com

这两个域名同属一个二级域名：b.com

4.2 跨域访问

nginx配置文件

服务器nginx增加以下配置，即可解决跨域访问的问题。也可以在程序中通过代码解决跨域访问。

location / {
    #是否允许跨域发送Cookie
    add_header Access-Control-Allow-Credentials true;
    add_header Access-Control-Allow-Origin 'http://a.b.com';
    add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
    add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';

    if ($request_method = 'OPTIONS') {
        return 204;
    }
}

4.3 跨域携带发送Cookie

如果需要允许跨域携带发送cookie的话，nignx则需要以下参数配置

nginx配置

（1）"Access-Control-Allow-Credentials"：可选字段。它的值是一个布尔值，表示是否允许发送Cookie。默认情况下，Cookie不包括在CORS请求之中。设为true，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。这个值也只能设为true，如果服务器不要浏览器发送Cookie，删除该字段即可。

（2）对于附带身份凭证的请求，服务器不得设置 Access-Control-Allow-Origin 的值为'*'。这是因为请求的首部中携带了Cookie信息，如果 Access-Control-Allow-Origin 的值为'*'，请求将会失败。而将 Access-Control-Allow-Origin 的值设置为 http://a.b.com，则请求将成功执行。也就是说Access-Control-Allow-Credentials设置为true的情况下 Access-Control-Allow-Origin不能设置为*。

前端配置
以vue请求为例：

import axios from 'axios';
axios.defaults.withCredentials=true //允许携带cookie

java设置cookie

public static void  addCookie(HttpServletResponse response,String cookieName,String cookieValue,int maxAge){
    Cookie cookie  =new Cookie(cookieName,cookieValue);
    cookie.setDomain("b.com");//指定域名
    cookie.setPath("/");//设置cookie的生命周期
    cookie.setHttpOnly(false);
    if(maxAge>0){
        cookie.setMaxAge(maxAge);
    }
    response.addCookie(cookie);
}