Day 2 : 接口及相关概念(2)

鉴权和授权

为什么有些页面我们能够直接访问,有些页面我们需要登录后才能访问呢?
比如说我想进入课堂派我首先要登录,输入我的账户密码然后点登录,因为只有这个账户登录进去后才能做我的操作,就好比银行一样,只有你的账号和你的密码你才能去操作你自己的账户,这个鉴权其实在生活中还是非常熟悉的,不光在我们的软件里面,其实在很多地方都是一样的,说白了就是要确定你是你,确定你有这个权力你有这个权限。

那么基于http协议的网络应用是如何进行权限管理的呢?

权限管理包含授权和鉴权
首先我要确定你是你,然后我给予你权限(授权),第二就是你再次发送http请求过来的时候我要鉴别你这个权限(鉴权),鉴定你这个权限是不是合法的,这个就是我们权限管理里面的授权和鉴权,一个是给予权力一个是鉴别权力,我们做测试的实际上只需要去鉴权,授权是由我们的服务端进行授权的,我们去授权的时候对于我们测试来说我们需要通过发送请求去获取权限然后再拿着权限做接下来的操作。
目前基于http协议的应用常见的权限管理方式有两大种方式 :会话技术和jwt’授权(token授权)。

1 .会话技术

前面讲到http是无状态有会话的,那么它有会话是基于我们的会话技术,就是基于cookie
http是无状态的,那服务端怎么区分同一个用户的连续请求呢?这就用到了会话技术:cookie 和 session

1.1 cookie技术

Cookie 有时也用其复数形式Cookies,英文是饼干的意思,指某些网站为了辨别用户身份,进行session(会话)跟踪而存储在用户本地终端上的数据(通常经过加密)
cookie和session有什么区别?
cookie存在客户端,用户的终端上面。一般情况下是加密的,cookie是由浏览器去处理的,浏览器在收到cookie的时候会帮我们自动去存储cookie,存在我们的电脑上面
cookie是依赖于我们http协议的头部扩展

Cookie其实就是由服务器发给客户端的特殊信息,而这些信息存放在客户端,然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息,服务器在接收到Cookie以后会验证Cookie的信息,以此来辨别用户的身份。
Cookie可以理解为一个凭证
cookie一般的保存格式为json格式,由一些属性组成,了解一下

  • name:Cookie的名称
  • value: Cookie 的值
  • domain:可以使用此Cookie的域名(域名的作用范围) 只有访问这个域名的时候这个cookie才会被携带
  • path: 可以使用此Cookie的页面路径 只有访问这个域名下的这个路径的时候,这个cookie才会被携带
  • expires/Max-Age: 此Cookie的超时时间 cookie的过期时间,有效时间
  • secure: 设置是否只能通过https来传递此条Cookie

·在这里插入图片描述
以课堂派为例,首先我要登录,我要填入我的用户名密码,然后我一点登录会发送一个http请求,把我们的用户名密码或者其他的一些需要权限验证的一些信息发送到我们的服务端,服务端接收到你这些权限的信息之后会在后端去校验你的用户名和密码是不是有效的,如果校验成功加密设置一个cookie信息返回响应,这个cookie信息就在响应头里面被返回给我们的客户端,客户端在接收到这个http响应之后,它会拿到这个cookie,然后把这个cookie存到我们本地的cookies文件里面,这是我们的授权。
浏览器在拿到响应的时候当他在响应头里面看到set-Cookie的时候,这个set-cookie就会保存我们的cookie信息,它就会把你后面设置的值这个就是我们的cookie信息,就会把它拿到然后存储到我们的浏览器的本地。在谷歌浏览器Cookies里面可以看到。

当我们登录课堂派的时候响应头会返回set-cookie(设置cookie),浏览器在拿到这个响应的时候当它在响应头里面看到这种set-cokokie的时候它就会把你后面设置的值,这个就是我们的cookie信息它就会把它拿到然后存储到浏览器的本地。这个set-cookie就是我们的响应请求头,那么浏览器就会保存我们的cookie信息,这个时候cookie会存储在浏览器的cookies文件里面。这个就是上面的过程。接下来我们的很多请求都是要携带cookie的。

我登录之课堂派后授权成功跳转到首页面,如果我刷新一下它还是在我的首页面,那么它是通过什么方式来判断的呢?是因为我在获取首页面的请求的时候我携带了cookie,如果我把这个cookies清掉(Application - Cookies),我再刷新这个地址的时候我就没有cookie,没有cookie的话,因为你接下来要访问我的首页面的时候是我要去检查你的cookie信息的,如果你没有cookie信息,那么我就觉得你没有权限,刷新一下就又跳转到登录页面了,因为鉴权失败,所以它会帮你重定向到登录,你需要重新登录,其实所有的鉴权都是这样的一个简单的流程,就是你需要有一个凭证、

set-Cokie 是我们的响应请求头,它会保存我们的cookie信息,在Cookies里面可以看到,接下来我们的很多请求都是要携带cookie的。

app或者小程序也会有处理cookie,只要是基于http协议的都会有这样的

我们cookies的原理是这样的
首先你到服务端要进行鉴权,鉴权成功之后它会给你一个cookie信息,这个cookie信息它会用响应发给你,浏览器会处理这个cookie把它存起来,接下来再发送请求的时候它会把这个cookie带上,那我们的服务端会校验这个cookie,如果它是合适的合法的那么就会把对应的数据给你,如果不合法他会有相应的处理,所有的像你们的客户端也好,你们的小程序,app也好,它们都有处理cookie的机制,所以你不用担心。

我们只要知道这个过程就可以了,对于我们用python做http接口自动化来说,我们不需要去手动处理cookie,我们知道有这个东西就可以了。

这个cookie因为在本地,在本地的话我们其实可以修改它,那既然你可以修改它,那么你的电脑如果被黑客挟持了是不是他也可以获取或者修改你的cookie?对于不重要的信息无所谓,如果你登录了银行网站,那个银行网站它也用这个cookie做权限校验,那么如果黑客获取了你银行网站的cookie,那他是不是可以登录你的银行?所以cookie有一个非常大的问题就是它的安全性比较低,因为所有的数据都是存在客户端的,甚至在过去刚开始的时候会把用户名和密码都存在cookie里面,虽然说加密了但是加密有时候是可以破解的,那么这就是cookie的一个很严重的问题,那么现在用cookie去存敏感的信息的方式其实已经被抛弃了,包括鉴权其实也不会用这个cookie,那么既然它有一个这样的弊端,存在你客户端的信息会比较不安全,那么如果我把它存在服务端呢?存在服务端那么服务端的技术会比客户端肯定是要高一些的,安全性更好一些,那我们能不能把用户的一些数据存在服务端呢?
所以在cookie的基础上又有了一个叫session的技术。session我们经常会把它翻译成会话.

1.2 session

Session,中文经常翻译为会话,其本来的含义是指有始有终的一系列动作/消息比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个session,这个词在各个领域都有在使用。
而我们的web领域,一般使用的是其本义,一个浏览器窗口从打开到关闭这个期间
Session的目的则是,在一个客户从打开浏览器到关闭浏览器这个期间,对同一个网站发起的所有请求都可以被识别为一个用户。

在这个地方我们把它称为session技术, session是依赖于cookie的,session是对cookie技术的一种利用,并不是说它有一个什么样的新的技术。
我们在这个地方把它称为session技术
那它怎么用呢?我们来换一种思路。
刚才我们说了,我们把cookie信息要存在客户端,那现在我们能不能把用户的会话信息存在服务端?

																																													{'   随机字符串' :“用户的会话信息‘(id,权限...)   }

在这里插入图片描述

现在我们就巧妙地用cookie技术来实现session技术
首先还是发送http请求,服务器接收到用户账号密码信息如果检验通过之后,我们会生成一个session_id ,这是一个随机字符串,那如果我们在后台维护可能是存在缓存服务器,可能是存在数据库,也可能是存在内存,也可能是存在文件,那我以内存为例,那我可以在后台这个地方存一个大字典,你来的时候校验成功我给你生成一个session_id(一个很长的随机字符串) ,我把随机字符串作为key,然后把用户的会话信息(这里面会存很多东西,比如你在数据库里面的id,你拥有的权限等等)我会把很多信息都存在这个字典里面,然后我返回数据的时候我把这个随机字符串我作为session_Id,把它放在coookie里面,返回给客户端,那这个时候我的客户端我存的就是session_Id,它只是一个字符串,当你下一次发送请求的时候,我把session_id拿到,把这个session_id 在cookie里面传过来,那我的服务端只需要在我的cookie信息里面获取到这个session_id,通过这个session_id到这个字典里面我就可以找到对应用户的信息,其实session的简单原理就是这样。
这样呢我们的session信息就存在了服务端,相对于cookie来说他就要安全一点,这个其实就是我们的session技术,没有什么特别的高大上,这就是session处理的流程

再举一个例子
什么是cookie呢?
我们把银行比作服务端,我们个人称为客户端,如果你要到银行去办业务你需要到银行开张卡,那么这个卡你每次到银行来,那你都需要带上这张卡,这个卡是不是你保管?这个卡其实就是cookie,这个卡谁给的?银行给的,你要办业务必须要带这张卡,银行只认卡不认人,这张银行卡就是cookie信息,那么什么是session呢?session就是你存在银行里面的信息,你的账户里面的钱,如果你想要要查到你账户里面的钱你需要把cookie拿过来,cookie就是你的银行卡,银行卡有卡号,通过卡号银行才能在他的系统里面查到你的账户然后查到你账户里面的信息,那你账户里面的信息就是session。这样cookie就不保存用户账号信息,它只保存session_id。服务器是不存cookie的,cookie是存在客户端的,服务器存的是session信息

去面试的时候
别人会问你这样的问题。 什么是cookie?什么是session?cookie和session的区别,那你把它说清楚就可以了
cookie就是指某些网站为了辨别用户身份,进行会话跟踪,存储在用户本地终端上的数据(通常经过加密)。
session是服务端利用cookie技术存储在服务端的用户的会话信息
他们的区别就是session信息是存储在我们的服务端,它会比cookie会安全,如果再说不清楚就把那个银行卡和银行的关系然后和你账户里面的信息你给它描述一遍其实就可以了。先听一下,随着后面摸索的时候你会回头对这些知识会有一个再去理解的一个过程,需要一个过程。
现在把这些概念听清楚就可以了,懂不懂你需要一定的时间

session认证的流程一般如下:

  1. 用户向服务器发送用户名和密码
  2. 服务器验证通过后,在当前对话(session)里保存相关数据,比如角色,登录时间等
  3. 服务器向用户返回一个session_id , 把这个session_id 写入用户的cookie
  4. 用户随后进行的每一次请求,都会通过cookie,将session_id 传回服务器
  5. 服务器收到session_id,找到前期保存的数据,由此得知用户的身份

因此session是基于cookie的

session与cookie相反,session是存储在服务器上的数据,只由客户端传上来的session_ld来进行判断,所以相对于cookie,session的安全性更高
一般sessionn_id会在浏览器被关闭时丢弃,或服务器会验证session的活跃程度,例如30分钟某一个session_id都没有活跃,那么也会被识别为失效

服务器不存cookie,服务器存的是session信息

这个了解一下就可以了,后面会学习用request去处理会话技术鉴权的时候非常简单,什么都不需要我们去做

在很久以前cookie就不会保存用户账号信息,只保存session_Id,服务器是不存cookie的, cookie是存在客户端的。服务器是存的是session信息。

2 JWT (token鉴权)

2.1 JWT原理

JSON WEB Token(缩写JWT)是目前最流行的跨域认证解决方案

因为cookie里面有一个domain(可以使用此cookie的域名,表示只有访问这个域名的时候这个cookie才会被携带),为了安全,cookie信息是不能跨域的,那什么叫跨域呢?就是这个网站上的cookie信息它只能在这个域名下去使用,这样就会造成一个问题 --> 一个服务可能会有不同的服务器,我们可能某一个产品,可能需要在服务器A去请求数据,还需要在服务器B去请求数据,用户需要在你的授权服务器去获取你的权限,然后去访问业务服务器上面的业务,但是这是两个不同的服务器,那它们的域名可能不一样,就意味着它们的网址不一样,而我们的浏览器会有一个同源策略的安全。
在这里插入图片描述

即你在这个域名上获取的cookie信息你不能用在另外一个域名上,默认是这样的,不然的话这个安全漏洞就会非常大,这个就是我们会话技术的局限,在过去我们网络的架构其实不是这样的,你的授权和你的业务在一台服务器上面,比如像一些小型的项目,我们现在很多项目都是这种分布式的,或者叫微服务,每个业务都是一个服务它们都是不同的域名,那么这样的话你用会话技术去鉴权的话会非常麻烦,你需要处理的信息比较多,所以就出现了token鉴权,它就是为了解决这种跨域。

JSON WEB Token(缩写JWT)是目前最流行的跨域认证解决方案
jwt的原理是,服务器认证之后,生成一个JSON对象,发回给用户,就像下面。

{
‘姓名’:“陈浩”,
“角色”:“管理员”
“到期时间”:“2020年10月1日0点0分”
}
这是以JWT举例子,不同项目的token鉴权是完全不一样的,它发给你的json对象是这样的,那它这个数据它不会直接给你的,它会经过一定的加密手段,加密完之后实际上我们的JWT,它的数据的格式跟下面的是一样的 有三段

以后,用户与服务端通信的时候,都要发回这个JSON对象,服务器完全只靠这个对象认定用户身份,为了防止用户篡改数据,服务器在生成这个对象的时候会加上签名(详见后文)
服务器就不保存任何session对象了,也就是说,服务器变成无状态了,从而比较容易实现扩展。

在这里插入图片描述
我们的用户登录请求,服务器还是做相应的处理去校验,你的用户名,你的密码,如果授权成功它会帮你返回一个像上面字典一样的数据(注意:这只是举个例子,不同项目的的token鉴权是完全不一样的),它发给你的json对象是上面那样的,但是它这个数据它不会直接给你,它会经过一定的加密手段,实际加密后 jwt 数据结构是下面这样的格式的
在这里插入图片描述
它是一个很长的字符串,中间用点(.) 分隔成三个部分,注意,JWT内部是没有换行的,这里指数为了便于展示,将它写成了几行。
JWT 的三个部分依次如下:

  • Header (头部)
  • Payload (负载,就是它的数据)
  • Signature (签名)

这里就涉及一些加密的算法,因为这里数据是怎么去加密的怎么去处理的其实它的服务器是知道的,那现在服务器发给你的token就是上面加密的这种,那你拿到这个token,下一次你要访问别的业务的时候,你就把这个token携带上,就通过http 携带这个token,前面讲过,我们的客户端发送数据给服务端我们可以通过哪些办法?我把这个token放在哪里?可以在请求头还可以在请求体里面(post),那么在请求头里面,我可以在cookie里面,因为cookie信息就是用请求头发送过去的,在请求体里面就比较简单了,我们用post发请求的时候放在请求体里面就可以了。那确实就是这样的。
在实际的场景,我们的token信息可以被放在请求头里面,也可以放在请求体里面,放在请求头里面呢就放在 Authorization :Bearer 这个请求头里面, 我们放到这个请求头里面之后,因为请求头是可以跨域的,所以你在请求头里面带上拿到token,你去访问其他的服务器的时候,那么其他的服务器就会从拿到请求头里面获取这个token,然后有授权的算法和鉴权的算法,它会把你这个token拿到把它解开,解开之后,它就会得到对应的数据,如果它解不开或者你的到期时间到了,你鉴权就失败了,它其实就是通过这种方式,这就是我们的token鉴权
这个你没有必要去详细了解它到底是怎么加密的这么去解密的,不同公司的算法是完全不一样的,我们要知道这个过程,其实这个过程跟我们前面讲的cookin 、session 其实是一样的,只不过token跨域可以放在不同的地方,可以放在请求体里面,并且token要生成,有时候我们可能需要知道这里加密算法是什么,可能需要开发帮你写一个接口,你去把对应的数据加密成token然后再去发送。比如后面讲前程贷,我们讲v3鉴权那就需要额外再加密,就需要写对应的加密模块。

token可以放在请求头里面也可以放在请求体里面。
在这里插入图片描述
客户端收到服务器返回的JWT,可以存储在Cookie里面,也可以存储在localStorage。
此后,客户端每次与服务器通信,都要带上这个JWT,你可以把它放在Cookie里面自动发送,但是这样不能跨域,所以更好的做法是放在HTTP请求的头信息Authorization字段里面。
Authorization: Bearer
另一种做法是,跨域的时候,JWT就放在POST请求的请求体里面
所以我们测试碰到JWT时要根据开发的使用方式进行对应的测试。

只要记住我们鉴权其实就是在请求里面带上不同的东西,如果是会话技术就带cookin,如果是token的话就带对应的token就可以了,
就把银行的例子记住就可以了,token也是一样,token也是那张卡,总之你要带一个令牌,你这个令牌拿到服务器,服务器会鉴别这个令牌,这就是我们的鉴权和授权。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值