全面了解Cookie

1、Cookie的出现

浏览器和服务器之间的通讯少不了HTTP协议,可是由于HTTP协议是无状态的,因此服务器并不知道上一次浏览器作了什么样的操做,这样严重阻碍了交互式Web应用程序的实现。程序员

针对上述的问题,网景公司的程序员创造了Cookie。跨域

2、Cookie的传输

服务器端在实现Cookie标准的过程当中,须要对任意HTTP请求发送Set-Cookie HTTP头做为响应的一部分:浏览器

  1. Set-Cookie: name=value; expires=Tue, 03-Sep-2019 14:10:21 GMT; path=/; domain=.xxx.com;安全

浏览器端会存储这样的Cookie,而且为以后的每一个请求添加Cookie HTTP请求头发送回服务器:性能优化

  1. Cookie: name=value服务器

服务器经过验证Cookie值,来判断浏览器发送请求属于哪个用户。cookie

3、浏览器中的Cookie

浏览器中的Cookie主要由如下几部分组成:dom

  • 名称:Cookie惟一的名称,必须通过URL编码处理。(同名会出现覆盖的状况)函数

  • 值:必须通过URL编码处理。性能

  • 域(domain):默认状况下cookie在当前域下有效,你也能够设置该值来确保对其子域是否有效。

  • 路径(path):指定Cookie在哪些路径下有效,默认是当前路径下。

  • 失效时间(expires):默认状况下,浏览器会话结束时会自动删除Cookie;也能够设置一个GMT格式的日期,指定具体的删除日期;若是设置的日期为之前的日期,那么Cookie会当即删除。

  • 安全标志(secure):指定以后只容许Cookie发送给https协议。

 

浏览器在发送请求时,只会将名称与值添加到请求头的Cookie字段中,发送给服务端。

浏览器提供了一个很是蹩脚的API来操做Cookie:

  1. document.cookie

经过上述方法能够对该Cookie进行写操做,每一次只能写入一条Cookie字符串:

  1. document.cookie = 'a=1; secure; path=/'

经过该方法还能够进行Cookie的读操做:

  1. document.cookie // "a=1"

因为上述方法操做Cookie很是的不直观,通常都会写一些函数来简化Cookie读取、设置和删除操做。

对于Cookie的设置操做中,须要如下几点:

对于名称和值进行URL编码处理,也就是采用JavaScript中的encodeURIComponent()方法; expires要求传入GMT格式的日期,须要处理为更易书写的方式,好比:设置秒数的方式; 注意只有的属性名的secure;

每一段信息须要采用分号加空格。

  1. function setCookie (key, value, attributes) {

  2. if (typeof document === 'undefined') {

  3. return

  4. }

  5. attributes = Object.assign({}, {

  6. path: '/'

  7. }, attributes)

  8.  

  9. let { domain, path, expires, secure } = attributes

  10.  

  11. if (typeof expires === 'number') {

  12. expires = new Date(Date.now() + expires * 1000)

  13. }

  14. if (expires instanceof Date) {

  15. expires = expires.toUTCString()

  16. } else {

  17. expires = ''

  18. }

  19.  

  20. key = encodeURIComponent(key)

  21. value = encodeURIComponent(value)

  22.  

  23. let cookieStr = `${key}=${value}`

  24.  

  25. if (domain) {

  26. cookieStr += `; domain=${domain}`

  27. }

  28.  

  29. if (path) {

  30. cookieStr += `; path=${path}`

  31. }

  32.  

  33. if (expires) {

  34. cookieStr += `; expires=${expires}`

  35. }

  36.  

  37. if (secure) {

  38. cookieStr += `; secure`

  39. }

  40.  

  41. return (document.cookie = cookieStr)

  42. }

Cookie的读操做须要注意的是将名称与值进行URL解码处理,也就是调用JavaScript中的decodeURIComponent()方法:

  1. function getCookie (name) {

  2. if (typeof document === 'undefined') {

  3. return

  4. }

  5. let cookies = []

  6. let jar = {}

  7. document.cookie && (cookies = document.cookie.split('; '))

  8.  

  9. for (let i = 0, max = cookies.length; i < max; i++) {

  10. let [key, value] = cookies[i].split('=')

  11. key = decodeURIComponent(key)

  12. value = decodeURIComponent(value)

  13. jar[key] = value

  14. if (key === name) {

  15. break

  16. }

  17. }

  18.  

  19. return name ? jar[name] : jar

  20. }

最后一个清除的方法就更加简单了,只要将失效日期(expires)设置为过去的日期便可:

  1. function removeCookie (key) {

  2. setCookie(key, '', { expires: -1 })

  3. }

介绍Cookie基本操做的封装以后,还须要了解浏览器为了限制Cookie不会被恶意使用,规定了Cookie所占磁盘空间的大小以及每一个域名下Cookie的个数。

为了绕开单域名下Cookie个数的限制,开发人员还创造了一种称为subcookie的概念,这里就不在赘述了,能够参考【JavaScript高级程序设计第23章 p633】。

4、服务端的Cookie

相比较浏览器端,服务端执行Cookie的写操做时,是将拼接好的Cookie字符串放入响应头的Set-Cookie字段中;执行Cookie的读操做时,则是解析HTTP请求头字段Cookie中的键值对。

与浏览器最大的不一样,在于服务端对于Cookie的安全性操碎了心

signed

当设置signed=true时,服务端会对该条Cookie字符串生成两个Set-Cookie响应头字段:

  1. Set-Cookie: lastTime=2019-03-05T14:31:05.543Z; path=/; httponly

  2. Set-Cookie: lastTime.sig=URXREOYTtMnGm0b7qCYFJ2Db400; path=/; httponly

这里经过再发送一条以.sig为后缀的名称以及对值进行加密的Cookie,来验证该条Cookie是否在传输的过程当中被篡改。

httpOnly

服务端Set-Cookie字段中新增httpOnly属性,当服务端在返回的Cookie信息中含有httpOnly字段时,开发者是不能经过JavaScript来操纵该条Cookie字符串的。

这样作的好处主要在于面对XSS(Cross-site scripting)攻击时,黑客没法拿到设置httpOnly字段的Cookie信息。

此时,你会发现localStorage相比较Cookie,在XSS攻击的防护上就略逊一筹了。 sameSite

在介绍这个新属性以前,首先你须要明白:当用户从http://a.com发起http://b.com的请求也会携带上Cookie,而从http://a.com携带过来的Cookie称为第三方Cookie。

虽然第三方Cookie有一些好处,可是给CSRF(Cross-site request forgrey)攻击的机会。

为了从根源上解决CSRF攻击,sameSite属性便闪亮登场了,它的取值有如下几种:

  • strict:浏览器在任何跨域请求中都不会携带Cookie,这样能够有效的防护CSRF攻击,可是对于有多个子域名的网站采用主域名存储用户登陆信息的场景,每一个子域名都须要用户从新登陆,形成用户体验很是的差。

  • lax:相比较strict,它容许从三方网站跳转过来的时候使用Cookie。

 

为了方便你们理解sameSite的实际效果,能够看这个例子:

  1. // a.com 服务端会在访问页面时返回以下Cookie

  2. cookies.set('foo', 'aaaaa')

  3. cookies.set('bar', 'bbbbb')

  4. cookies.set('name', 'cccccc')

  5.  

  6. // b.com 服务端会在访问页面时返回以下Cookie

  7. cookies.set('foo', 'a', { sameSite: 'strict' })

  8. cookies.set('bar', 'b', { sameSite: 'lax' })

  9. cookies.set('baz', 'c')

如何如今用户在a.com中点击连接跳转到b.com,它的请求头是这样的:

  1. Request Headers

  2.  

  3. Cookie: bar=b; baz=c

5、网站性能优化

Cookie在服务端和浏览器的通讯中,主要依靠HTTP的响应头和请求头传输的,因此Cookie会占据必定的带宽。

前面提到浏览器会为每一次HTPP请求自动携带上Cookie信息,可是对于同站内的静态资源,服务器并不须要处理其携带的Cookie,这无形中便浪费了带宽。

在最佳实践中,通常都会将静态资源部署到独立的域名上,从而能够避免无效Cookie的影响。