web Python,python web程序

　　Yyds干货库存

　　前言：

　　作者介绍：Its Dream，华为云分享专家，博客年度明星，CSDN Force项目作者，Python领域优质创作者，专注分享Python领域原创系列文章。

　　我们根据接口文档写了代码，从前端处理客户API请求。

　　并且我们还编写了用户登录处理的代码。不知道大家有没有发现问题？

　　前端发送的客户API请求直接由我们的后端代码处理，不需要验证这个请求是否是登录的管理员发送的。

　　如果是这样的话，客户端登录后就可以直接进入首页，不需要登录。我们写的登录处理代码有什么用？

　　这要求我们在处理客户API请求之前，确定发出请求的用户是否已经登录。

　　通常有两种验证请求消息有效性的方案：会话和令牌。

　　一、会话方案会话就是会话。会话方案的原理如下：

　　服务器在数据库中保存一个会话表。此表记录了有关用户登录的信息。

　　记录什么信息因系统而异。通常会记录用户的ID、姓名和登录名。

　　1.1会话id django中的表名是django_session，如下所示。

　　您可以发现会话id(表中的session id)通常是用于标记会话的字符串。并且对应于该会话的数据在这里被加密。

　　通过这个表，服务器可以根据会话号(通常称为会话ID)找到会话的信息数据。

　　角色：

　　1.用户成功登录后，服务器会在数据库会话表中创建一条记录来记录该会话。

　　也就是说，创建一个新的sessionid并将其插入到表中。

　　同时，将会话对应的一些数据放入记录的数据字段，比如登录用户的信息。

　　然后，在登录请求的HTTP响应消息中，sessionid数据被填入。

　　像这样

　　set-Cookie:session id=6 qu 1 cuk 8 CX vtf 4 w9 rjxeppexh 2 izy 0 hh

　　根据http协议，这个Set-Cookie字段意味着前端需要将数据存储在Cookie中。然后，当访问服务器时，这些cookie数据必须与HTTP请求消息一起获取。

　　Cookie通常是存储在客户端浏览器中的一些数据。服务器可以通过http响应消息请求浏览器存储一些数据。

　　以后每次访问相同的网站服务，都必须在HTTP请求中携带这些cookie中的数据。

　　Cookie由多个键值对组成，例如：

　　session id=6 qu 1 cuk 8 CX vtf 4 w9 rjxeppexh 2 izy 0 hh

　　用户名=byhy

　　收藏夹=手机_笔记本电脑_手表

　　2.用户的后续操作，即触发的HTTP请求，将在请求头的Cookie字段中引入前面提到的sessionid。

　　如下所示：

　　cookie:session id=6 qu 1 cuk 8 CX vtf 4 w9 rjxeppexh 2 izy 0 hh

　　服务器收到请求后，只需要检查session表中是否有sessionid对应的记录，就可以判断该请求是否是之前登录过的用户发出的。

　　如果没有，您可以拒绝该服务，并将http请求重定向到登录页面，让用户登录。

　　1.2实际操作首先，我们启动服务器：

　　然后输入我们的网址：http://127 . 0 . 0 . 1:8080/mgr/sign . html进入登录页面：

　　第二，令牌机制使用会话机制来验证用户请求的合法性。有两个主要缺点：

　　性能问题

　　因为认证请求根据sessionid在数据库中查找会话表，而数据库操作是服务器常见的性能瓶颈，尤其是用户数量比较大的时候。可扩展性问题

　　当系统中有大量用户时，后端通常会有多个处理请求的服务器，部署在多个节点上。但是多个节点要访问会话表，这就要求数据库服务可以被多个节点访问，而且不方便拆分数据库来提高性能。最近流行的令牌机制可以较好地解决这些问题。

　　简单来说，token就是包含数据信息和验证信息的数据包。

　　会话机制是将数据信息(如会话表)放在服务器上，服务器数据不能被客户篡改，从而保证了验证的可靠性。

　　令牌机制数据信息直接传输给客户端，客户端的每个请求都被带回给服务器。服务器不需要查数据库，直接根据令牌中的数据信息进行检查。

　　那么问题来了：客户数据是直接发给客户端的。客户端篡改数据怎么办，比如把自己改成vip用户？服务器如何验证数据是否被客户端篡改(术语是完整性验证)？

　　令牌机制的原理如下：

　　1.服务器配置了秘钥，秘钥由服务器私有保存，不能泄露。

　　2.用户登录成功后，服务器对用户的信息数据密钥一起进行哈希计算，得到哈希值。

　　注意：哈希算法保证哈希值只能从相同的源数据中获得。如果任何人修改了用户信息，除非他知道密钥，否则他可以通过再次使用哈希算法来获得正确的新哈希值。所以这个哈希值用于检查数据是否被修改过。

　　然后把用户数据信息和哈希值做成一个字节串，叫做token。

　　您可以发现令牌包含用户数据信息和用于验证完整性的哈希值。

　　然后，这个令牌在服务器返回给客户的HTTP响应中返回。令牌通常放在HTTP响应的头部。具体哪个头字段不指定，开发者可以自己定义。

　　3.用户的后续操作，触发的HTTP API请求，会在请求消息中带token。

　　在特定请求消息中存储令牌的位置由开发人员自己定义，通常也存储在http请求的头中。

　　服务器收到请求后，会根据数据信息和密钥，使用哈希算法重新生成哈希值。

　　如果客户端因为不知道密钥，无法获得正确的新哈希值而修改数据信息，那么服务器根据被篡改的数据密钥获得的新哈希值必然与令牌中存储的旧哈希值不同。我知道数据被修改了。如果客户端没有修改数据，服务器根据原始数据密钥得到的哈希值与令牌中存储的原始哈希值一致，验证通过。在验证之后，我们确定数据没有被修改，我们可以安全地使用token中的数据进行后续的业务逻辑处理。

　　在上述处理中，由于服务器不需要访问搜索数据库，因此处理性能大大提高。

　　第三，使用session来验证客户机请求Django对session的支持在默认情况下是可用的。让我们看看如何加入API请求的验证。您是否注意到，在我们处理登录的前一个函数中，有一行代码由下面的箭头指示：

　　这行代码的作用是将用户类型保存到登录认证后的会话数据中，也就是之前数据库中该人物的会话数据记录。

　　Django框架将自动在HTTP响应消息的头中添加类似于下面的sessionid cookie

　　Set-Cookie: sessionid=？

　　后续的HTTP请求将携带这个会话id，

　　我们需要向API请求代码添加一个验证逻辑，该代码的URL以/api/mgr开头。

　　验证请求的cookie中是否有sessionid，并检查会话表，查看是否有session_key作为sessionid的记录，以及该记录的数据字典是否包含usertype作为mgr的数据。

　　在前面的代码中，这些请求都是在dispatcher entry函数中处理的，所以我们只需要在dispatcher中验证它们。

　　修改mgr/customer.py的调度函数：

　　在前面添加以下代码：

　　#如果“usertype”不在request.session中，则确定用户是否为已登录的管理员用户：如果request.session [usertype]，则返回JSON响应({ret: 302， msg: not logged in ， redirect:/mgr/sign.html}，status=302。= mgr :返回JSON响应({ret: 302， msg :用户不属于mgr类型， redirect :/mgr/sign . html }，status=302)

　　请注意，请求对象中的会话属性对应于会话记录中的数据。

　　这个数据对象类似于一个字典，所以检查是否有任何用户类型类型管理器的信息，它是这样写的：

　　if request.session[usertype]！= mgr 来自博客作者为梦想原创作品，转载请联系作者获得授权，否则将追究法律责任。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。