前端工作的小伙伴怎么能不了解Cookie。今天小编就为大家带来了这篇文章,让我们一起来看一看Web前端新手应该了解的Cookie知识。
一、Cookie的出现
浏览器和服务器之间的通信少不了HTTP协议,但是因为HTTP协议是无状态的,所以服务器并不知道上一次浏览器做了什么样的 *** 作,这样严重阻碍了交互式Web
应用程序的实现。
针对上述的问题,网景公司的程序员创造了Cookie。
二、Cookie的传输
服务器端在实现Cookie标准的过程中,需要对任意HTTP请求发送Set-CookieHTTP头作为响应的一部分:
1.Set-Cookie:name=valueexpires=Tue,03-Sep-201914:10:21GMTpath=/
domain=.#
浏览器端会存储这样的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=1securepath=/'
通过该方法还可以进行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.lengthi
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.543Zpath=/httponly
2.Set-Cookie:lastTime.sig=URXREOYTtMnGm0b7qCYFJ2Db400path=/
httponly
这里通过再发送一条以.sig为后缀的名称以及对值进行加密的Cookie,来验证该条Cookie是否在传输的过程中被篡改。
httpOnly
服务端Set-Cookie字段中新增httpOnly属性,当服务端在返回的Cookie信息中含有httpOnly字段时,开发者是不能通过JavaScript来 *** 纵该条Cookie字符串的。
这样做的好处主要在于面对XSS(Cross-sitescripting)攻击时,黑客无法拿到设置httpOnly字段的Cookie信息。
此时,你会发现localStorage相比较Cookie,在XSS攻击的防御上就略逊一筹了。sameSite
在介绍这个新属性之前,首先你需要明白:当用户从#发起#的请求也会携带上Cookie,而从#携带过来的Cookie称为第三方Cookie。
虽然第三方Cookie有一些好处,但是给CSRF(Cross-siterequestforgrey)攻击的机会。
为了从根源上解决CSRF攻击,sameSite属性便闪亮登场了,它的取值有以下几种:
·
strict:浏览器在任何跨域请求中都不会携带Cookie,这样可以有效的防御CSRF攻击,但是对于有多个子域名的网站采用主域名存储用户登录信息的场景,每个子域名都需要用户重新登录,造成用户体验非常的差。
·lax:相比较strict,它允许从三方网站跳转过来的时候使用Cookie。
为了方便大家理解sameSite的实际效果,可以看这个例子:
1.//#服务端会在访问页面时返回如下Cookie
2.cookies.set('foo','aaaaa')
3.cookies.set('bar','bbbbb')
4.cookies.set('name','cccccc')
5.
6.//#服务端会在访问页面时返回如下Cookie
7.cookies.set('foo','a',{sameSite:'strict'})
8.cookies.set('bar','b',{sameSite:'lax'})
9.cookies.set('baz','c')
如何现在用户在#中点击链接跳转到#,它的请求头是这样的:
1.RequestHeaders
2.
3.Cookie:bar=bbaz=c
五、网站性能优化
Cookie在服务端和浏览器的通信中,主要依靠HTTP的响应头和请求头传输的,所以Cookie会占据一定的带宽。
前面提到浏览器会为每一次HTPP请求自动携带上Cookie信息,但是对于同站内的静态资源,服务器并不需要处理其携带的Cookie,这无形中便浪费了带宽。
在最佳实践中,一般都会将静态资源部署到独立的域名上,从而可以避免无效Cookie的影响。
以上就是小编今天为大家分享的关于Web前端新手应该了解的Cookie知识,希望本篇文章能够对正在从事Web前端工作和准备从事Web
前端学习的小伙伴们有所帮助。想要了解更多Web前端相关知识记得关注北大青鸟Web培训官网!
作者|descire
来源|#/article/286535
*声明:内容与图片均来源于网络(部分内容有修改),版权归原作者所有,如来源信息有误或侵犯权益,请联系我们删除或授权事宜
当网页要发http请求时,浏览器会先检查是否有相应的cookie,有则自动添加在request header中的cookie字段中。这些是浏览器自动帮我们做的,而且每一次http请求浏览器都会自动帮我们做。这个特点很重要,因为这关系到“什么样的数据适合存储在cookie中”。
存储在cookie中的数据,每次都会被浏览器自动放在http请求中,如果这些数据并不是每个请求都需要发给服务端的数据,浏览器这设置自动处理无疑增加了网络开销;但如果这些数据是每个请求都需要发给服务端的数据(比如身份认证信息),浏览器这设置自动处理就大大免去了重复添加 *** 作。所以对于那种设置“每次请求都要携带的信息(最典型的就是身份认证信息)”就特别适合放在cookie中,其他类型的数据就不适合了。
不同的浏览器存放的cookie位置不一样,也是不能通用的。
cookie的存储是以域名形式进行区分的,不同的域下存储的cookie是独立的。
我们可以设置cookie生效的域(当前设置cookie所在域的子域),也就是说,我们能够 *** 作的cookie是当前域以及当前域下的所有子域
一个域名下存放的cookie的个数是有限制的,不同的浏览器存放的个数不一样,一般为20个。
每个cookie存放的内容大小也是有限制的,不同的浏览器存放大小不一样,一般为4KB。
cookie也可以设置过期的时间,默认是会话结束的时候,当时间到期自动销毁
cookie值既可以设置,也可以读取。
我们通过document.cookie来获取当前网站下的cookie的时候,得到的字符串形式的值,它包含了当前网站下所有的cookie(为避免跨域脚本(xss)攻击,这个方法只能获取非 HttpOnly 类型的cookie)。它会把所有的cookie通过一个分号+空格的形式串联起来,例如username=chenfangxujob=coding
要想修改一个cookie,只需要重新赋值就行,旧的值会被新的值覆盖。但要注意一点,在设置新cookie时,path/domain这几个选项一定要旧cookie 保持一样。否则不会修改旧值,而是添加了一个新的 cookie。
把要删除的cookie的过期时间设置成已过去的时间,path/domain/这几个选项一定要旧cookie 保持一样。
如果我们想长时间存放一个cookie。需要在设置这个cookie的时候同时给他设置一个过期的时间。如果不设置,cookie默认是临时存储的,当浏览器关闭进程的时候自动销毁
使用方法: setCookie('username','cfangxu',30)
domain指定了 cookie 将要被发送至哪个或哪些域中。默认情况下,domain 会被设置为创建该 cookie 的页面所在的域名,所以当给相同域名发送请求时该 cookie 会被发送至服务器。
浏览器会把 domain 的值与请求的域名做一个尾部比较(即从字符串的尾部开始比较),并将匹配的 cookie 发送至服务器。
cookie 一般都是由于用户访问页面而被创建的,可是并不是只有在创建 cookie 的页面才可以访问这个 cookie。 因为安全方面的考虑,默认情况下,只有与创建 cookie 的页面在同一个目录或子目录下的网页才可以访问。即path属性可以为服务器特定文档指定cookie,这个属性设置的url且带有这个前缀的url路径都是有效的。
domain是域名,path是路径,两者加起来就构成了 URL,domain和path一起来限制 cookie 能被哪些 URL 访问。 所以domain和path两个个选项共同决定了cookie何时被浏览器自动添加到请求头部中发送出去。如果没有设置这两个选项,则会使用默认值。domain的默认值为设置该cookie的网页所在的域名,path默认值为设置该cookie的网页所在的目录。
通常 cookie 信息都是使用HTTP连接传递数据,这种传递方式很容易被查看,所以 cookie 存储的信息容易被窃取。假如 cookie 中所传递的内容比较重要,那么就要求使用加密的数据传输。
secure选项用来设置cookie只在确保安全的请求中才会发送。当请求是HTTPS或者其他安全协议时,包含 secure 选项的 cookie 才能被发送至服务器。
把cookie设置为secure,只保证 cookie 与服务器之间的数据传输过程加密,而保存在本地的 cookie文件并不加密。就算设置了secure 属性也并不代表他人不能看到你机器本地保存的 cookie 信息。机密且敏感的信息绝不应该在 cookie 中存储或传输,因为 cookie 的整个机制原本都是不安全的
注意:如果想在客户端即网页中通过 js 去设置secure类型的 cookie,必须保证网页是https协议的。在http协议的网页中是无法设置secure类型cookie的。
这个选项用来设置cookie是否能通过 js 去访问。默认情况下,cookie不会带httpOnly选项(即为空),所以默认情况下,客户端是可以通过js代码去访问(包括读取、修改、删除等)这个cookie的。
当cookie带httpOnly选项时,客户端则无法通过js代码去访问(包括读取、修改、删除等)这个cookie。 在客户端是不能通过js代码去设置一个httpOnly类型的cookie的,这种类型的cookie只能通过服务端来设置。
HTML5新方法,不过IE8及以上浏览器都兼容。
生命周期:持久化的本地存储,除非主动删除数据,否则数据是永远不会过期的。
存储的信息在同一域中是共享的。
当本页 *** 作(新增、修改、删除)了localStorage的时候,本页面不会触发storage事件,但是别的页面会触发storage事件。
大小:据说是5M(跟浏览器厂商有关系)
localStorage本质上是对字符串的读取,如果存储内容多的话会消耗内存空间,会导致页面变卡
localStorage受同源策略的限制
当storage发生改变的时候触发。 当页面对storage的 *** 作会触发其他页面的storage事件,storage事件是可以跨页面通讯的,在你对storage对象进行任何 *** 作的时候,都会触发storage事件,事件里边包括包括:
storage事件使用参考
对于sessionStorage和localStorage上的任何更改都会触发storage事件,但storage事件不会区分这两者
其实跟localStorage差不多,也是本地存储,会话本地存储
和 localStorage 的API完全相同
用于本地存储一个会话(session)中的数据,这些数据只有在同一个会话中的页面才能访问并且当会话结束后数据也随之销毁。因此sessionStorage不是一种持久化的本地存储,仅仅是会话级别的存储。也就是说只要这个浏览器窗口没有关闭,即使刷新页面或进入同源另一页面,数据仍然存在。关闭标签页后,sessionStorage即被销毁,或者在新的标签页打开同源的另一个页面,sessionStorage也是没有的。
应用的场景有,比如说我们都知道,在页面刷新的时候,我们写的js里边的变量函数等等的,内存会被释放掉,那么这个时候可以用sessionStorage来存储一些不想被释放掉内存的数据,比如说记录一个滚动条的位置,或者播放器的进度等等
在本地(浏览器端)存储数据
sessionStorage和localStorage 都受到同源策略限制,就是跨域问题,在访问sessionStorage和localStorage 的时候,页面必须在同一个域名,使用同一个协议,并且一个端口
sessionStorage比localStorage更严苛一点,除了协议、主机名、端口外,还要求在同一窗口(也就是浏览器的标签页)下。
localStorage是永久存储,除非手动删除。
sessionStorage当会话结束(当前页面、标签页关闭的时候,自动销毁)
cookie的数据会在每一次发送http请求的时候,同时发送给服务器而localStorage、sessionStorage不会。
sessionStorage和localStorage 也有大小限制,相比cookie大了很多,是5M
sessionStorage和localStorage只能通过客户端 *** 作,cookie既可以通过客户端 *** 作又可以通过服务端 *** 作
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)