现在很多接口项目在登录的时候返回一个token，登录后的拿着这个token去访问访问登录之后的请求。 本篇使用djangorestframework框架写一个登陆的接口，登录成功后返回token。 环境准备： python 3.6 django 2.1.2
在Django REST Framework中，BasicAuthentication是最简单的身份验证之一，它基于HTTP基本身份验证标准。
近期在项目开发练习中用到了登录功能 + 验证码的需求，验证码一般分为三种类型：图片验证码、短信验证码、滑动验证码，相关实现思路如下
上述操作中均是对单独视图进行特殊配置，如果想要对全局进行配置，则需要再配置文件中写入即可。
在公司中，有很多开发，每个人维护的api接口是不一样的。如果有一个统一的api文档管理平台，每个开发，把自己维护的接口录入进去。
后端只能收到前端发送的请求头，请求参数，及资源定位符（url）。在没有用户认证的情况下，无论前端是谁，只要发送的请求一样，后端返回的数据也是一样的，前端人人平等，后端对他们一视同仁。
200 OK - [GET]：服务器成功返回用户请求的数据，该操作是幂等的（Idempotent）。 201 CREATED - [POST/PUT/PATCH]：用户新建或修改数据成功。 202 Accepted - [*]：表示一个请求已经进入后台排队（异步任务） 204 NO CONTENT - [DELETE]：用户删除数据成功。 400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。 401 Unauthorized - [*]：表示用户没有权限（令牌、用户名、密码错误）。 403 Forbidden - [*] 表示用户得到授权（与401错误相对），但是访问是被禁止的。 404 NOT FOUND - [*]：用户发出的请求针对的是不存在的记录，服务器没有进行操作，该操作是幂等的。 406 Not Acceptable - [GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）。 410 Gone -[GET]：用户请求的资源被永久删除，且不会再得到的。 422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。 500 INTERNAL SERVER ERROR - [*]：服务器发生错误，用户将无法判断发出的请求是否成功。 更多看这里：http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 状态码
网络应用程序，分为前端和后端两个部分。当前的发展趋势，就是前端设备层出不穷（手机、平板、桌面电脑、其他专用设备......）。
现在，前端与后端分处不同的域名，这就涉及到跨域访问数据的问题，因为浏览器的同源策略，默认是不支持两个不同域间相互访问数据，而我们需要在两个域名间相互传递数据，这时我们就要为后端添加跨域访问的支持。
然后迁移数据库，会生成一张表authtoken_token，存放用户的token信息：
转载原文：https://cloud.tencent.com/developer/article/1097993
Django和Django REST framework（后简称DRF）提供了海量的全局配置、局部配置，来实现上述思想，但配置项太多了，有时人们往往不知道该如何利用。
Github和Gitee代码同步更新： https://github.com/PythonWebProject/Django_Fresh_Ecommerce； https://gitee.com/Python_Web_Project/Django_Fresh_Ecommerce。
签发：一般我们登录成功后签发一个token串，token串分为三段，头部，载荷，签名
七、用户登录与手机注册 7.1.drf的token （1）INSTALL_APP中添加 INSTALLED_APPS = ( ... 'rest_framework.authtoken
用户登录后，才有操作当前用户的权限，不能操作其它人的用户，这就是需要用到权限认证，要不然你登录自己的用户，去操作别人用户的相关数据，就很危险了。
-多年互联网运维工作经验，曾负责过大规模集群架构自动化运维管理工作。 -擅长Web集群架构与自动化运维，曾负责国内某大型金融公司运维工作。 -devops项目经理兼DBA。 -开发过一套自动化运维平台（功能如下）： 1)整合了各个公有云API，自主创建云主机。 2)ELK自动化收集日志功能。 3)Saltstack自动化运维统一配置管理工具。 4)Git、Jenkins自动化代码上线及自动化测试平台。 5)堡垒机，连接Linux、Windows平台及日志审计。 6)SQL执行及审批流程。 7)慢查询日志分析web界面。
为了验证用户登录情况以及减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。有些登录不是用 cookie 来验证的，是用 token 参数来判断是否登录。token 传参有两种一种是放在请求头里，本质上是跟 cookie 是一样的，只
在完成了登录和注册视图之后，需求中还需要管理员可以管理用户列表，所以就需要完成基础的增删改查操作
为了这种情况下每次都要decode，loads，显得麻烦，所以才有的解析器。弥补了django的缺点
一、基础 1.1.安装 两种方式： github pip直接安装 pip install django-rest-framework 1.2.需要先了解的一些知识 理解下面两个知识点非常重要，django-rest-framework源码中到处都是基于CBV和面向对象的封装 （1）面向对象封装的两大特性 把同一类方法封装到类中 将数据封装到对象中 （2）CBV 基于反射实现根据请求方式不同，执行不同的方法 原理：url-->view方法-->dispatch方法（反射执行其它方法：GET/POST/P
跨站请求伪造（Cross-Site Request Forgery：CSRF），也被称为 One-Click Attack 或者 Session Riding，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。与跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。
1、安装 pip install djangorestframework 2、创建项目及应用 创建过程略 目录结构如图 3、设置settings.py 设置数据库连接 # MySQL 增加mysql
APIView：DRF提供的所有视图的基类，继承View并扩展，具备了身份认证、权限检查、流量控制等功能
Django可以用LoginRequiredMixin和PermissionRequiredMixin给类视图添加认证和权限，DRF做了高级封装，提供了更简洁的实现方式。我们通过继续学习官网教程来进行了解。
REST是一种软件架构设计风格，不是标准，也不是具体的技术实现，只是提供了一组设计原则和约束条件。
博客：https://www.jianshu.com/u/9fcd71535294
写下这篇文章，一方面记录Django REST framework的体验过程，同时借此解读下REST架构风格。
2021年，测试平台如雨后春笋般冒了出来，我就是其中一员，写了一款pytest内核测试平台，在公司落地。分享出来后，有同学觉得挺不错，希望能开源，本着“公司代码不要传到网上去，以免引起不必要麻烦”的原则，只能在家从头写一个，边重新梳理代码边温习巩固知识点，以学习交流为目的，定义为“学习版”。
使用base64加密之后的header + . + 使用base64加密之后的playload + 使用HS256算法加密，同时secret加盐处理
官方:http://getblimp.github.io/django-rest-framework-jwt/
在RESTful API中，接口返回的是JSON，JSON的内容对应的是数据库中的数据，DRF是通过序列化（Serialization）的技术，把数据模型转换为JSON的，反之，叫做反序列化（deserialization）。本文就来揭开DRF序列化技术的神秘面纱。
话说什么是基本认证？ 在HTTP协议进行通信的过程中，HTTP协议定义了基本认证过程以允许HTTP服务器对WEB浏览器进行用户身份证的方法，当一个客户端向HTTP服务 器进行数据请求时，如果客户端未被认证，则HTTP服务器将通过基本认证过程对客户端的用户名及密码进行验证，以决定用户是否合法。
Web 开发中前后端分离已经是常规性做法，但是不少初学者不太熟悉如何前后端分离，搭建 Demo 的时候遇到的问题也比较多，今天就来分享一下如何用 Vue 和 Django 快速搭建前后端分离项目。
接收参数>>>验证数据的完整性>>>验证密码和确认密码是否一致>>>验证邮箱是是否正确(正则)>>>查看用户是否已经注册>>>将用户信息保存到数据库中>>>对用户信息进行加密并发送邮件任务
目录 不会DRF？源码都分析透了确定不来看？ 快速使用DRF写出接口 序列化和反序列化 drf快速使用 views.py serializer.py urls.py 在settings的app中注册 models.py postman测试 CBV源码流程分析 Django View和DRF APIView的小插曲 DRF之APIView和Request对象分析 APIView的执行流程 Request对象分析 原来的django中没有request.data，造一个！ 不会DRF？源码都分析透了确定不来看？
在本文中，我们将从Python Web开发人员的角度看处理Web身份验证的最常用方法。
6.QQ服务器响应时让客户端重定向访问callback回调网址，并携带code和state参数。
在视图中处理业务逻辑。django约定将视图放在views.py的文件中。这个文件应放在项目或者应用目录中。
Web 后端在主流场景下，注定成为了仅仅提供 API 接口和进行一些需要消耗服务器性能和后端计算载体；
在前后端分离开发时为什么需要用户认证呢？原因是由于HTTP协定是不储存状态的(stateless)，这意味着当我们透过帐号密码验证一个使用者时，当下一个request请求时它就把刚刚的资料忘了。于是我们的程序就不知道谁是谁，就要再验证一次。所以为了保证系统安全，我们就需要验证用户否处于登录状态。
上一篇讲了基于类的视图，在REST framework中，你也可以使用常规的基于函数的视图。它提供了一组简单的装饰器，用来包装你的视图函数， 以确保视图函数会收到Request（而不是Django一般的HttpRequest)对象，并且返回Response（而不是Django的HttpResponse）对象，同时允许你设置这个请求的处理方式。
我们将使用 django-rest 创建一个简单的API，以允许管理员用户查看和编辑系统中的user和group。
用Python如何写一个接口呢，首先得要有数据，可以用我们在网站上爬的数据，在上一篇文章中写了如何用Python爬虫，有兴趣的可以看看：
注意：permission_classes设置的是：验证的是用户是否登录、用户是否可以操作该数据等的权限；
Django REST Framework（DRF）提供了各种身份验证选项，以确保您的API端点仅对授权用户可用。
我们知道，我们不管路由怎么写的，对应的视图类怎么写的，都会走到dispatch方法，进行分发，
1.用户访问app系统，app系统是需要登录的，但用户现在没有登录。 2.跳转到CAS server，即SSO登录系统，后续图中的CAS Server统一叫做SSO系统。SSO系统也没有登录，弹出用户登录页。 3.用户填写用户名、密码，SSO系统进行认证后，将登录状态写入SSO的session，浏览器（Browser）中写入SSO域下的Cookie。 4.SSO系统登录完成后会生成一个ST（Service Ticket），然后跳转到app系统，同时将ST作为参数传递给app系统。 5.app系统拿到ST后，从后台向SSO发送请求，验证ST是否有效。 6.验证通过后，app系统将登录状态写入session并设置app域下的Cookie。 至此，跨域单点登录就完成了。以后我们再访问app系统时，app就是登录的。
领取专属 10元无门槛券
手把手带您无忧上云
