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 问题描述

参考: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);
}
浏览器 文章被收录于专栏

浏览器

全部评论

相关推荐

10-13 17:47
门头沟学院 Java
wulala.god:图一那个善我面过,老板网上找的题库面的
点赞 评论 收藏
分享
评论
1
收藏
分享
牛客网
牛客企业服务