一、cookie出现原因
http是无状态的,浏览器无法记录当前是哪个人浏览的,所以出现了cookie
作用:会话状态管理(用户登录状态、购物车、游戏分数)、个性化设置(主题、自定义设置)、浏览器行为跟踪(跟踪分析用户行为)
二、cookie作用过程
服务器可以在 HTTP 请求响应标头中添加一个或多个 Set-Cookie 属性来设置 cookie,它是由键/值对以及可选属性组成的相应字符串:
Set-Cookie: myfirstcookie=somecookievalue
cookie 是服务器可以存储在用户浏览器并保存到本地中的小块数据,浏览器收到响应后通常会保存下 Cookie,并将其放在 HTTP Cookie
标头内,向同一服务器发出请求时一起发送(会造成一定性能开销)。
Cookie: myfirstcookie=somecookievalue
三、cookie属性值
1.过期时间max-age和expires
默认情况下,cookie 在用户关闭会话时即关闭浏览器时过期(不过有一些浏览器重启的时候会使用会话恢复延长会话时间)。要持久化cookie,我们可以通过expires
或Max-Age
属性
Set-Cookie: myfirstcookie=somecookievalue; expires=Tue, 09 Jun 2020 15:46:52 GMT; Max-Age=1209600
expires:在指定时间失效,设置成过去的时间代表立即删除cookie
Max-Age:在多少秒之后失效,如果设置为-1代表立即失效
注意:Max-Age优先于expires。
2.定义cookie发送的位置: path 和domain
Domain
和 Path
标识定义了 Cookie 的作用域:即允许 Cookie 应该发送给哪些 URL。
-
Domain属性
Domain
指定了哪些主机可以接受 Cookie。如果不指定,该属性默认为同一 host 设置 cookie,不包含子域名。如果指定了 Domain
,则一般包含子域名。
例如,如果设置
Domain=mozilla.org
,则 Cookie 也包含在子域名中(如developer.mozilla.org
)。
注意:
1.设置domain之后,端口号和协议不一致不会影响cookie
2.设置domain为.mozilla.org
和设置为mozilla.org
效果是一样的,但是如果不设置,默认为mozilla.org
,此时只在当前域下(不包括子域)
3.在子域中可以给父域设置cookie,比如:
可以在a.com和b.a.com中获取到这个cookie
4.不能在当前域的子域或者跨域设置cookie,比如:
-
Path属性
Path
属性指定了一个 URL 路径,该 URL 路径必须存在于请求的 URL 中,并且子路径也会被匹配
例如,设置
Path=/docs
,则以下地址都会匹配:
/docs
/docs/
/docs/Web/
/docs/Web/HTTP
具有给定路径path属性的cookie不能被发送到另一个不相关的路径,即使这两个路径位于同一域中。
注意:在cookie创建过程中省略Path
时,浏览器默认为/
。
3.cookie的安全保证:secure和HttpOnly
-
secure属性
标记为 Secure
的 Cookie 只应通过被 HTTPS 协议加密过的请求发送给服务端,它永远不会使用不安全的 HTTP 发送(本地主机除外),可以预防中间人攻击
注意:当我们设置secure属性之后去访问http网站是不会带着这个cookie的
-
HttpOnly属性
设置了 HttpOnly 属性的 cookie 不能使用 JavaScript 经由 Document.cookie
属性、XMLHttpRequest
和 Request
APIs、Cookie Store
APIs 进行访问。(通过接口网络数据可以看到,但是不能通过代码拿到),可以有效的防止XSS攻击
注意:只能通过服务器的set-cookie设置,我们自己设置会被浏览器忽略掉
4.跨站请求时不会被发送:SameSite属性
服务器要求某个 Cookie 在跨站请求(顶级域名和二级域名一样认为是同站)时不会被发送,从而可以阻止CSRF攻击。
-
SameSite 属性有三个可选值
1. None
:无论是否跨站都会发送cookie
2. Strict
:跨站不会携带cookie
3. Lax
:新版本浏览器默认设置为 Lax。与Strict
类似,但特定条件也可发送跨域请求。
- URL 必须发生变化
- HTTP 请求方式必须是安全的,例如
GET
、HEAD、
OPTIONS
,它们不改变数据举个例子,用户从 a.com 跳转到 b.com,URL 发生了变化的同时请求方式为 GET,所以 设置了
Lax
的 Cookie 会被发送过去 ,除此之外还有图片加载、iframe 调用等等。
-
SameSite 和 Domain 的区别
Domain
属性限制了接收 Cookie 的域名,而 SameSite
属性限制了发送 Cookie 的域名
举个例子:
Set-Cookie: Foo=bar; Path=/; Secure; Domain=scar.site;
无论是从
scar.site
还是foo.example.com
发起的请求,只要被发送到了scar.site
或者它的子域名,那 Cookie 就能发过去。Set-Cookie: name=scar; Path=/; Secure; Domain=scar.site;SameSite=strict;
如果设置了
SameSite=strict
,那么这个请求只能从scar.site
发起 Cookie 才能带过去。
四、cookie携带注意事项
1.同源策略下会自动携带
如果请求的 URL 域名、路径、协议与 Cookie 设置的 Domain
和 Path
属性匹配,浏览器会自动将符合条件的 Cookie 附加到请求头的 Cookie
字段中
Domain
属性
Domain
属性指定 Cookie 可以被访问的域名,默认为当前域名,只能被设置它的域名或其子域名访问。示例:
如果 Cookie 设置为
Domain=example.com
,它可以在example.com
和sub.example.com
下访问。如果 Cookie 设置为
Domain=sub.example.com
,它只能在sub.example.com
下访问。
Path
属性
Path
属性指定 Cookie 可以被访问的路径,默认为/,只能被设置它的路径或其子路径访问。示例:
如果 Cookie 设置为
Path=/api
,它可以在/api
及其子路径(如/api/v1
)下访问。如果 Cookie 设置为
Path=/
,它可以在整个域名下访问。
2. 跨域请求的受限携带
跨域请求中 cookie 的携带受到 CORS(跨域资源共享)的限制。默认情况下,浏览器不会在跨域请求中发送 cookie,需要服务器配置 CORS 头。
为了允许跨域请求携带 cookie,服务器需要返回特定的响应头:
- 设置 Access-Control-Allow-Origin 为请求的源,而不是通配符 *,因为 * 不允许携带 cookie
- 设置Access-Control-Allow-Credentials 为 true,这样浏览器才会发送 cookie。
- 根据需求配置 Access-Control-Allow-Methods、Access-Control-Allow-Headers 等
- Cookie 的 SameSite 属性未设置为 Strict 或 Lax。若需跨站携带,需设置为 SameSite=None; Secure(仅限 HTTPS)
3.子域名与父域名的交互
-
父域名 Cookie 影响子域名:
若父域名(example.com)设置了 Cookie,子域名(api.example.com)的请求不会自动携带该 Cookie,除非显式设置Domain=.example.com
-
子域名 Cookie 不影响父域名:
子域名(api.example.com)设置的 Cookie(未显式设置Domain)仅在该子域名下有效,父域名(example.com)的请求不会携带它
五、如何判断两个 Cookie 是否是同一个 Cookie
同一个cookie:相同的名称(Name)、域(Domain)、路径(Path)
Cookie 覆盖条件
-
相同的名称、域和路径:如果新设置的 Cookie 的名称、域和路径与已存在的 Cookie 完全相同,那么新 Cookie 会覆盖旧 Cookie。
-
服务器设置新的 Cookie:当服务器通过
Set-Cookie
响应头设置一个新 Cookie 时,如果新 Cookie 的名称、域和路径与现有 Cookie 完全匹配,浏览器会用新 Cookie 替换旧 Cookie。
如果想对cookie做进一步了解,可看下面的文章:
Cookie 从入门到进阶:一文彻底弄懂其原理以及应用-阿里云开发者社区
前端必要懂的,完整的 HTTP cookie 指南 - 终身学习者 - SegmentFault 思否
浏览器自动携带cookie注意事项_cookie 什么时候会自动带上-CSDN博客
前端Cookie手把手教程哔哩哔哩bilibili