好程序员Web 前端教程分享 新手应该了解的Cookie 知识！

　　一、Cookie 的出现

 

　　浏览器和服务器之间的通信少不了HTTP 协议，但是因为 HTTP 协议是无状态的，所以服务器并不知道上一次浏览器做了什么样的操作，这样严重阻碍了交互式 Web 应用程序的实现。

 

　　二、Cookie 的传输

 

　　服务器端在实现Cookie 标准的过程中，需要对任意 HTTP 请求发送 Set-CookieHTTP 头作为响应的一部分：

 

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

 

　　浏览器端会存储这样的Cookie ，并且为之后的每个请求添加 CookieHTTP 请求头发送回服务器：

 

　　1.Cookie:name=value

 

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

 

　　三、浏览器中的Cookie

 

　　浏览器中的Cookie 主要由以下几部分组成：

 

　　·名称： 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.functionsetCookie(key,value,attributes){

 

　　2.if(typeofdocument==='undefined'){

 

　　3.return

 

　　4.}

 

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

 

　　6.path:'/'

 

　　7.},attributes)

 

　　8.

 

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

 

　　10.

 

　　11.if(typeofexpires==='number'){

 

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

 

　　13.}

 

　　14.if(expiresinstanceofDate){

 

　　15.expires=expires.toUTCString()

 

　　16.}else{

 

　　17.expires=''

 

　　18.}

 

　　19.

 

　　20.key=encodeURIComponent(key)

 

　　21.value=encodeURIComponent(value)

 

　　22.

 

　　23.letcookieStr=`${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.functiongetCookie(name){

 

　　2.if(typeofdocument==='undefined'){

 

　　3.return

 

　　4.}

 

　　5.letcookies=[]

 

　　6.letjar={}

 

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

 

　　8.

 

　　9.for(leti=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.returnname?jar[name]:jar

 

　　20.}

 

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

 

　　1.functionremoveCookie(key){

 

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

 

　　3.}

 

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

 

　　四、服务端的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-sitescripting) 攻击时，黑客无法拿到设置 httpOnly 字段的 Cookie 信息。

 

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

 

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

 

　　虽然第三方Cookie 有一些好处，但是给 CSRF(Cross-siterequestforgrey) 攻击的机会。

 

　　为了从根源上解决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.RequestHeaders

 

　　2.

 

　　3.Cookie:bar=b;baz=c

 

　　五、网站性能优化

 

　　Cookie 在服务端和浏览器的通信中，主要依靠 HTTP 的响应头和请求头传输的，所以 Cookie 会占据一定的带宽。

 

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