赔率网站怎么做,网站建设私人接单,网络营销产品价格策略,网站热图分析cookie 纳入标准文档#xff0c;标准浏览器需要遵守的协议之一#xff0c;作为标准浏览器必须支持的。 WEB应用都是基于HTTP协议#xff0c;标准的HTTP协议是无状态的。 什么是无状态#xff1f; 不管是谁#xff0c;不管是从哪个地方发起的请求。只要你的请求#xff08… cookie 纳入标准文档标准浏览器需要遵守的协议之一作为标准浏览器必须支持的。 WEB应用都是基于HTTP协议标准的HTTP协议是无状态的。 什么是无状态 不管是谁不管是从哪个地方发起的请求。只要你的请求URL包括了域名甚至包括了具体的文件【当然也有缺省的情况 即默认访问】是一样的你拿到的结果【响应】永远是一样的。 这样就导致了一些需求无法完成比如 我想让第一次访问该页面的用户给他重定向到welcome页面接着是它想访问的页面而之后继续访问该页面【第二次及以后】则不会去访问welcome页面。 这种根据用户访问次数来做的需求就无法实现。 因此我们提出了cookie的概念。 由于HTTP本身是无状态的那么我就把状态本身附加到响应头head中。 同时这个cookie是符合HTTP标准协议里面的即任何一个标准的浏览器都应该支持这个功能。当我们服务器在响应的时候只要我们设置一个响应的字段“set-cookie”。 浏览器在收到响应之后如果它发现响应头里面有“set-cookie”字段那么浏览器就会把对应的key-value保存在浏览器里面并且以后浏览器向同一个域名发起请求的时候浏览器是会携带这个cookie【放在请求头中】 虽然HTTP本身是无状态的但服务器把需要的状态以cookie的形式返回给浏览器让浏览器来帮忙。服务器后续想更新这个cookie也是同样在响应头进行更新及扩充。 cookie的不足 我们会发现这些cookie都是明文暴露在外面的泄漏了很多后台管理的状态使得它有一定的安全问题甚至一些企业中的安全策略内网会把cookie给禁掉。 2、引入了session session 通过后台来保存这些状态保存完之后为了区分不同的session起名为session上下文每个上下文有一个对应的sessionID然后我们只把sessionID通过cookie返回回去。这样浏览器拿到的也就只有sessionID很大程度避免了信息的泄漏。 session的不足 当一个服务是多地部署的这样当两次请求发给的是不同的服务器如第一次发给了北京的服务器而第二次发给了上海的服务器在第二次的时候只拿到了sessionID而没有session上下文于是就需要回到北京的服务器去查。造成了性能的开销。 token 后端把需要保存的内容不保存在服务器里【当然也可以在服务器中拷贝一份】后端将session上下文的状态打包成token同时把token做加密我只认token不认人。交给【返回给】前端前端在发后续请求的时候把token和请求发给后端后端收到请求之后把 token解包 -- 可以看到token里面的内容【前端一般不会主动去打开token】。对于分布式服务器服务相同的一个session请求的时候如果连续两次请求的是不同地段的服务器我也不需要去查之前的服务器了因为上下文的状态全保存在token中。 当设置token的时候可以通过secret进行加密也可以设置过期时间。 当后端进行校验工作确认信息没问题的时候根据业务把相关信息进行打包将token返回给前端当前端拿到token的时候也只是拿到了一个令牌【前端是解不开的因为我们正常是不会把secret传给前端】在下次发请求的时候会把token放入请求头里【的authorization】发给后端。 token不是标准协议的内容完全是前后端之间自己去定义、协商的。通常都是把token放入请求头里和请求一起发过来在拿到token之后去验证它 验证secret对不对签名是否过期。当不满足上述条件则直接返回401
