接口测试基础——session认证和token认证
总算是把这个过程理清楚了,现在我们的思路是:what?why?How?,实际上这些个机制产生的内部逻辑是从下至上的的:遇到问题了,想办法解决,总结归纳并取名。从解决一些小问题开始生长,不断打补丁直至完善。学习接口,永远有个认识:这是客户端 和 服务器的之间的交流,可以类别为 用户 和 超市!
什么是session?
Http协议是无状态的,Session是一种让请求从无状态变成有状态的机制,实现session的方式有很多种,通过地址栏,借助cookie(cookie就是存在浏览器里的一些信息,以一个文件夹的形式存在,里面的信息是由服务端产生的)。
基于session的身份认证
借助cookie,客户端登陆成功后,服务端就能识别其后续请求,而不需要每次都登陆。
为解决数据被篡改的问题:
一种是把cookie里面的内容加密,但这种方法有两个缺点:1)cookie的大小是有限制的,2)加密方式以及密钥有泄露的风险
另一种方法是通过一个ID来辨别身份,这个ID称之为seesion id,Server只在Cookie里面存一个Session id,其余的状态都存在Server那边,可以存在数据库或内存里。其具体的认证过程如下:
1) 客户端登陆,一般输入用户名和密码
2) 服务端如果验证通过,生成session,并把它存入数据库中,并将其中的session id存放在Set-Cookie当中发给客户端
3) 客户端接收到Set-Cookie,在浏览器上会产生cookie,并把session id写入
4) 客户端后续有新的请求,都会在请求后携带sessIon id,发给服务端,服务端进行验证
5) 如果客户端登陆出去(log out),该生成的session就会在客户端和服务端都被销毁
基于session认证的不足
服务端存储每个用户的session,当用户很多时,需要大量的资源
不能很好解决跨域资源共享问题
什么是Token?
token的意思是“令牌”,是服务端生成的一串字符串,作为客户端进行请求的一个标识。
简单token的组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名,token的前几位以哈希算法压缩成的一定长度的十六进制字符串,为防止token泄露)。
基于token机制的身份认证
Token是服务端用自己的密钥签名的,当它收到客户带有Token的请求时,只需要再用自己的密钥去验证,就可以判断这个Token是不是自己签发的。这里面的核心就是用签名和验证,从而减轻了服务端的负担,无需再存储session。大概的流程:
1) 客户端使用用户名和密码请求登录
2) 服务端验证,验证通过,生成Token返还给客户端(一般用哈希算法,再加个随机数)。
3) 客户端收到token后把它存储起来,可以放在cookie或者Local Storage(本地内存)里
4) 客户端以后每次向服务端发送请求的时候都需要带上该token。
5) 服务端收到请求时验证Token,如果验证通过,则允许用户访问相应资源)
token认证与session认证的区别
token认证中,服务端不会保存token,再次访问只会对token中携带的信息进行验证,session认证服务器会给每一个session分配唯一的session id保存在服务端的数据库中,再次访问时浏览器通过cookie把session id传回给服务器,服务器根据session id找到第一次登陆时所分配的session对象
使用基于Token认证可以使API应用到不同的服务和域中