在php 用cookie技术时遇到的问题,如何在一台机子上设置多个用户cookie?

在php 用cookie技术时遇到的问题,如何在一台机子上设置多个用户cookie?,第1张

你想像游戏里登陆那样,在同一台电脑上有以前登陆过的账号?把最后登陆过的为默认像是吧!

你可以把登陆过的都保存到同一个COOKIE(保存时间多久就看你了)里啊!,就是数据要处理下,比如第一次保存1:时间,第二次就把第一次的取出和第一次的拼接在存入,若是有了就更新时间,如:1:时间|2:时间......。推荐弄成JSON,而数据就用数组,array('id'=>'时间'),再把它弄成JSON数据,在存COOKIE

应用鉴权就是当一个用户进入APP时,我们需要判断他所拥有的权利,根据权力来判断他所能进行的一个行为,最为常见的就是购物网站的登录以及购物支付等 *** 作。

Http的请求是无状态的,就是说在一个Http请求中的请求方和响应方都是无法维护状态,是一次性的,所以我们就不知道请求前后都发生了什么。所以我们需要标记的功能,而浏览器的sessionStorage,localStorage,全局变量等限制太多,就有了cookie,session,token等鉴权的 *** 作。

cookie也是一种前端存储的方式,但是他和sessionStorage,localStorage等本地存储的不同在于,浏览器向服务端发起请求的时候,cooike是自动传过去的,可以做到前端无感知,出错的概率更低

过程:

1.浏览器向服务器发起请求并传送数据,由服务器接收数据然后设置cooike放进响应头(Set-Cookie),浏览器接收到响应之后就会自动存储进cookie

2.在之后的每一次请求中浏览器都会自动的在请求头之中设置cookie字段,发送给服务端

配置:

1.Domain/Path

cookie 是要限制空间范围的,通过 Domain(域)/ Path(路径)两级。

2.Expires / Max-Age

cookie 还可以限制时间范围,通过 Expires、Max-Age 中的一种。

3.Secure / HttpOnly

cookie 可以限制使用方式。

Http头对cookie的读写:

响应会携带一个Set-Cookie头,一个Set-Cookie只能设置一条cookie,格式为cookie键值+配置键值,如果想要一次设置多个cookie,我们可以多写几个Set-Cookie在头里面。

而当浏览器请求服务器的时候,就不再需要发送配置内容了,只需要发送键值对就可以

前端对cookie的读写 *** 作:

如果服务端设置的cookie并没有设置httpOnly,那么我们就可以调用document.cookie来对cookie进行读写 *** 作,但一次调用document.cookie就只能 *** 作一个cookie

在上面我们介绍了cookie,可以了解到cookie其实是浏览器存储的一种实现,可以看作应用鉴权的基石。但是它只是一个存储信息的工具,我们还需要判断其中的信息是不是安全的 *** 作者,这时候我们就需要session了。

典型的session登录流程:

session的存储与过期销毁:

由于session是用来验证的,所以服务端仅仅只是给浏览器的cookie中添加一个sessionid,所以也需要自己保存一下,存储的方式:

而session也可以手动设置过期时间,一到过期时间就直接清空存储的内存就好了

session的分布式问题:

由于服务端是集群,而用户请求过来会走一次负载均衡,不一定会打到哪台机器上。一旦用户后续接口请求到的机器和他登录请求的机器不一样,或者登录请求的机器出问题了,那session就会失效。

常见的解决方式:

目前主流的token存储还是在cookie中进行,但是为了防止伪造token造成的安全问题,我们还需要一些加密算法来生成签名,来保证数据安全性

业务接口用来鉴权的 token,我们称之为 access token。越是权限敏感的业务,我们越希望 access token 有效期足够短,以避免被盗用。但过短的有效期会造成 access token 经常过期,过期后怎么办呢?

一种办法是,让用户重新登录获取新 token,显然不够友好,要知道有的 access token 过期时间可能只有几分钟。

另外一种办法是,再来一个 token,一个专门生成 access token 的 token,我们称为 refresh token。

如果refresh token过期了,就只能重新登陆了。

客户端存cookie与存放于其他地方

1.出了浏览器环境之外就没有cookie了;

2.cookie是浏览器在域下自动携带的。很容易引发CSFR攻击

存放在别的地方可以解决部分问题

服务端存储数据于不存

1.存数据的话可以缩短认证字符串的长度,减小请求体积

2.不存数据就不会出现分布式处理的问题,降低硬件成本,避免查库带来的验证延迟

前面我们已经知道了,在同域下的客户端/服务端认证系统中,通过客户端携带凭证,维持一段时间内的登录状态。

但当我们业务线越来越多,就会有更多业务系统分散到不同域名下,就需要「一次登录,全线通用」的能力,叫做「单点登录」。

主域名相同 的情况下,就可以直接把cookie设置为主域名就可以实现了。

如果 主域名不同 ,我们就需要独立的认证服务,称为SSO。

如果是在浏览器之下实现,我们需要考虑其他的东西

对浏览器来说,SSO 域下返回的数据要怎么存,才能在访问 A 的时候带上?浏览器对跨域有严格限制,cookie、localStorage 等方式都是有域限制的。

这就需要也只能由 A 提供 A 域下存储凭证的能力。一般我们是这么做的:

图中我们通过颜色把浏览器当前所处的域名标记出来。注意图中灰底文字说明部分的变化。

1.HTTP 是无状态的,为了维持前后请求,需要前端存储标记

2.cookie 是一种完善的标记方式,通过 HTTP 头或 js *** 作,有对应的安全策略,是大多数状态管理方案的基石

3.session 是一种状态管理方案,前端通过 cookie 存储 id,后端存储数据,但后端要处理分布式问题

4.token 是另一种状态管理方案,相比于 session 不需要后端存储,数据全部存在前端,解放后端,释放灵活性

5.token 的编码技术,通常基于 base64,或增加加密算法防篡改,jwt 是一种成熟的编码方案

6.在复杂系统中,token 可通过 service token、refresh token 的分权,同时满足安全性和用户体验

7.session 和 token 的对比就是「用不用cookie」和「后端存不存」的对比

8.单点登录要求不同域下的系统「一次登录,全线通用」,通常由独立的 SSO 系统记录登录状态、下发 ticket,各业务系统配合存储和认证 ticket

阅读知乎文章: 鉴权必须了解的5个兄弟:cookie、session、token、jwt、单点登录 - 知乎 (zhihu.com)


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/bake/11605456.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-17
下一篇 2023-05-17

发表评论

登录后才能评论

评论列表(0条)

保存