Cookie、sessionStorage和localStorage
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 问题描述
需要解决前端跟服务端,跨域后都能获取到同一个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); }
浏览器