Cookie
服务器在 HTTP 响应中, 通过Set-Cookie
命令浏览器存储一个cookie(通常不大于4KB)并为其配置属性
- 注意,多个同名cookie只要其他属性有任何一个不同,就不会相互覆盖,而是都存起来。
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco;Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
Set-Cookie: tasty_cookie=strawberry; Secure; path=/blog
[page content]
此后浏览器每次对Cookie的Domain对应的域发起HTTP请求时,自动把这个Cookie携带到请求的Header中
- 和请求地址有关,当前网页URL无关。如当前网页为A,对B发起了请求,则带上的为B的cookies,和A无关
GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry
cookie属性
- Domain
域名,下次浏览器访问该域名时会带上cookie - Path
限制具体路径,如果路径不能匹配时,即使Domain符合条件也不发送Cookie - Name、Value
实际有意义的数据,浏览器请求符合条件的地址时会带上该数据 - Expires、Max-Age
过期日期和最大失效时间,同时设置时Max-Age
生效。若均为设置则为Session Cookie
,本次浏览器关闭时即清空 - Secure
为 true 时,cookie 仅在 HTTPS 中才有效 - HttpOnly
为 true 时,通过程序(JS 脚本document.cookie
、applet 等)将无法读取到COOKIE 信息,防止 XSS 攻击产生 - Singed
表示是否签名cookie, 设为true 会对这个 cookie 签名,这样就需要用 res.signedCookies 而不是 res.cookies 访问它。被篡改的签名 cookie 会被服务器拒绝,并且 cookie 值会重置为它的原始值 - SameSite
用来限制第三方 Cookie,从而防止CSRF攻击。- Strict
只有当前网页的 URL 与请求目标一致,才会带上 Cookie。
由于从当前网页打开一个新页面也算一种请求,会导致打开其他域下的网页时,页面请求也不带cookie,此时如果是后端渲染就无法读取到信息了 - Lax (默认值)
允许导航到目标网址的 Get 请求获取cookie - None
不做任何限制
为保证安全,只有在cookie同时具有Secure
属性时才能设置为None
- Strict
document.cookie
document.cookie属性用于读写当前网页的 Cookie。
- 读取时仅可获得无
HTTPOnly
的cookie - 写入时一次只能写入一个,需写成key=value形式,且必须对分号、逗号和空格进行
encodeURIComponent
转义(它们都不允许作为 Cookie 的值)
document.cookie = 'fontSize=14; '
+ 'expires=' + someDate.toGMTString() + '; '
+ 'path=/subdirectory; '
+ 'domain=*.example.com';
- 删除一个现存 Cookie 的唯一方法,是设置它的expires属性为一个过去的日期
Session
Session是一种服务端的机制,服务器使用哈希表结构(key-value)来保存信息。通过客户端请求传入的key进行匹配,以识别客户端的身份。
Session通常借助Cookie或Storage将key存在浏览器端,通过redis将key-value对照关系存在服务器端
一个常见的校验方式
- 生成3个COOKIE,分别使用用户名,登录时间,用户名+登录时间DES加密后的密文
- 使用COOKIE与SESSION进行比对验证
- 使用JWT生成TOKEN,解密出被加密的部分进行验证。
JWT
将用户信息加密后直接传给前端作为token,前端每次请求带上该token,服务器端解密后直接获得用户信息。比起普通的Session认证,不依赖cookie和session,不受CSRF攻击,信息不用存储在服务器端(节省开销且利于分布式系统)。
网友评论