当前位置:首页 » 网页前端 » 前端cookies
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

前端cookies

发布时间: 2022-09-13 07:28:42

⑴ cookie前端存储有哪几种

1、cookie
HTTP cookie,通常直接叫做cookie,是客户端用来存储数据的一种选项,它既可以在客户端设置也可以在服务器端设置。cookie会跟随任意HTTP请求一起发送。
优点:兼容性好
缺点:一是增加了网络流量;二则是它的数据容量有限,最多只能存储4KB的数据,浏览器之间各有不同;三是不安全。
2、userData
userData是微软通过一个自定义行为引入的持久化用户数据的概念。用户数据允许每个文档最多128KB数据,每个域名最多1MB数据。
缺点:userData不是 web 标准的一部分,只有IE支持。
3、web存储机制
web storage,包括两种:sessionStorage 和 localStorage,前者严格用于一个浏览器会话中存储数据,因为数据在浏览器关闭后会立即删除;后者则用于跨会话持久化地存储数据。
缺点:IE不支持 SessionStorage,低版本IE ( IE6, IE7 ) 不支持 LocalStorage,并且不支持查询语言
4、indexedDB
indexed Database API,简称为indexedDB,是在浏览器中保存结构化数据的一种“数据库”。它类似SQL数据库的结构化数据存储机制,代替了废弃已久的web SQL Database API,它能够在客户端存储大量的结构化数据,并且使用索引高效检索的API。
缺点:兼容性不好,未得到大部分浏览器的支持。
5、Flash cookie
Flash本地存储,类似于HTTP cookie,它是利用 SharedObject类来实现本地存储信息。它默认允许每个站点存储不超过100K的数据,远大于cookie,而且能够跨浏览器。
缺点:浏览器需安装 Flash 控件,毕竟它是通过Flash的类来存储。所幸的是,没有安装Flash的用户极少。
6、Google Gears
Google Gears是Google在07年发布的一个开源浏览器插件,Gears 内置了一个基于SQLite的嵌入式 SQL数据库,并提供了统一API 对 数据库进行访问,在取得用户授权之后,每个站点可以在SQL数据库中存储“不限大小”的数据。
缺点:需要安装 Google Gears 组件

⑵ web 前端 js cookie

我有一个思路不知道适不适用你的场景

if($("#js_ads_banner_top_slide").length&&getCookie("bannershow")=="1"){
var$slidebannertop=$("#js_ads_banner_top_slide"),$bannertop=$("#js_ads_banner_top");
setTimeout(function(){$bannertop.slideUp(1000);$slidebannertop.slideDown(1000);},2000);
setTimeout(function(){
$slidebannertop.slideUp(1000,function(){
$bannertop.slideDown(1000);
});
document.cookie="bannershow=1";//存cookie
},6000);
}
//获取cookie
functiongetCookie(name){
vararr,reg=newRegExp("(^|)"+name+"=([^;]*)(;|$)");
if(arr=document.cookie.match(reg)){
returnunescape(arr[2]);
}else{
returnnull;
}
}



望采纳!谢谢~

⑶ 前端cookie有哪些神秘的特点呢

cookie有如下几个特点:
1.域的限制;
2.时间限制;
3.空间限制,cookie只能存储4kb;
4.数量限制,每个域下最多不能超过50个cookie;
5.存储数据类型限制,cookie只能存储字符串;

⑷ Web前端新手应该了解的Cookie知识!

今天小编要跟大家分享的文章是关于Web前端新手应该了解的Cookie知识。正准备学习Web前端知识和准备从事Web
前端工作的小伙伴怎么能不了解Cookie。今天小编就为大家带来了这篇文章,让我们一起来看一看Web前端新手应该了解的Cookie知识。

一、Cookie的出现


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


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


二、Cookie的传输


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


1.Set-Cookie:name=value;expires=Tue,03-Sep-201914:10:21GMT;path=/;
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=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
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


在介绍这个新属性之前,首先你需要明白:当用户从#发起#的请求也会携带上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=b;baz=c

五、网站性能优化


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


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


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


以上就是小编今天为大家分享的关于Web前端新手应该了解的Cookie知识,希望本篇文章能够对正在从事Web前端工作和准备从事Web
前端学习的小伙伴们有所帮助。想要了解更多Web前端相关知识记得关注北大青鸟Web培训官网!


作者|descire


来源|#/article/286535


*声明:内容与图片均来源于网络(部分内容有修改),版权归原作者所有,如来源信息有误或侵犯权益,请联系我们删除或授权事宜

⑸ cookie及其常用属性值

Cookie通过在客户端记录信息确定用户身份,Session通过在服务器端记录信息确定用户身份。

expires是当前cookie的过期时间。max-age是当前cookie经过多少秒失效,等于0是关闭浏览器立即失效,小于0是cookie无效 立即删除。max-age的优先级比exprises高。

path:路径,指定与cookie关联的web,目录或路径,

"/"  凡是来自同一服务器,URL里有相同路径的所有web页面都可以共享cookies。

domain:域,指定关联的web服务器或域,值是域名,如果我们想让www.achome.cn能够访问bbs.achome.cn设置的cookies,该怎么办? 我们可以把domain属性设置成“achome.cn”,并把path属性设置成“/”。

secure:安全,指定cookie的值通过网络如何在用户和服务器之间传递。不设置或为空的情况就是使用不安全的HTTP链接传递数据。否则就是通过HTTPS或者其他安全协议传递数据。

本地的cookie文件并不加密。

samesite:(strict、lax、none)

strict最严格,完全禁止第三方cookie,跨站点时任何情况都不发送cookie。当前URL与请求目标一致才会带上cookie。

lax除了导航到目标网址的get请求外大多数情况也不发送第三方cookie,允许链接、预加载、get 表单携带cookie,但post表单、iframe、ajax等不允许携带cookie。基本也杜绝了CSRF攻击。

none任何时候都带上cookie。

HTTPonly:安全性,客户端脚本无法通过document.cookie等方式获取读写。有助于避免xss攻击。

CSRF攻击:cookie往往用来存储用户的身份信息,恶意网站可以设法伪造带有正确cookie的HTTP请求。第三方网站诱导发出的cookie,称为第三方cookie。

设置cookie:响应头中的set-cookie 前端设置cookie。同站same-site 二级域名+顶级域名,相等即可。www.lilnong.top 主机名.二级域名.顶级域名。同源和跨域same-origin 和cross-origin 。

⑹ 怎么让shiro给前端发cookie

shiro如何返回cookie给前端shiro如何返回cookie给前端。
有个springboot项目,登录和权限采用shiro管理,某天前端开发人员突然说小程序页面里面无法把cookie传递给后端。

⑺ 前端如何跨域拿到cookie

前后端分离,最应该用token来交互,而不是用cookie。当然是可以取得cookie的。所有的cookie 都在头里面,有个Set-Cookie的字段,读取这个头就可以了。
Token是令牌。HTTP是无状态的,Cookie是记录HTTP状态的一种手段。浏览器会通过Set-Cookie字段获取Cookie。而Token是通过oauth认证后得到的令牌。

⑻ 后端设置的cookie,前端能控制失效时间吗

不能。
后端写cookie对前端来说就是个黑盒子,我只要向后端发送申请,就可以拿到当前用户的信息,尽管我不知道用户的id。操作简单,理解起来不太友好。所以前端不能修改。

⑼ 前端中怎样设置cookie

你好,可以参考这个网址的教程。前端开发中的cookie使用总结。

⑽ 说一下前端数据存储方式(cookies,localstorage,sessionstorage,indexedDB)的区别

Cookie最初是在客户端用于存储会话信息的,其要求服务器对任意HTTP请求发送Set-CookieHTTP头作为响应的一部分。cookie
以name为名称,以value为值,名和值在传送时都必须是URL编码的。浏览器会存储这样的会话信息,在这之后,通过为每个请求添加Cookie
HTTP头将信息发送回服务器。

localstorage

存储方式:

以键值对(Key-Value)的方式存储,永久存储,永不失效,除非手动删除。

sessionstorage

HTML5 的本地存储 API 中的 localStorage 与 sessionStorage 在使用方法上是相同的,区别在于 sessionStorage 在关闭页面后即被清空,而 localStorage 则会一直保存。

IndexedDB

索引数据库(IndexedDB) API(作为 HTML5 的一部分)对创建具有丰富本地存储数据的数据密集型的离线 HTML5 Web 应用程序很有用。同时它还有助于本地缓存数据,使传统在线 Web 应用程序(比如移动 Web 应用程序)能够更快地运行和响应。