网站推广的软件,大学生网页设计期末作业,学生可做的网站主题,上海网站建设自学我们前面经过数据库的学习已经基本了解了怎么接受前端发过来的请求#xff0c;并处理后返回数据实现了一个基本的登录登出效果#xff0c;但是存在一个问题#xff0c;我们是将所有的请求都直接处理了#xff0c;并没有去检查是否为已经登录的管理员发送的#xff0c;如果… 我们前面经过数据库的学习已经基本了解了怎么接受前端发过来的请求并处理后返回数据实现了一个基本的登录登出效果但是存在一个问题我们是将所有的请求都直接处理了并没有去检查是否为已经登录的管理员发送的如果是这样的话客户端可以不选择登录直接去访问主页文件那么登录就毫无意义了。 所以我们要在处理前端请求前先去判断这个请求的合法性通常的两种方案就是session 和token 一、session方案
1、session原理 session 表示会话的意思Django在服务端在数据库中保存一张session表 这个表中记录了用户登录的信息具体的信息各个系统都略有不同大致都会有id、姓名、登录名称之类的在下图中我们可以看到存储着session_key(会话ID) 、session_data 会话数据可以发现sessionid 通常就是 一串字符串 用来标记一个session的。 而session对应的数据在这里是加密的通过这张表服务端 可以根据 session号通常叫session ID 查到 session 的信息数据。 每当用户成功登录之后服务端都会往数据库表session中记录一条数据也就是创建一个新的会话id写入数据表同时也 放入一些 该session对应的数据到 记录的数据字段中比如登录用户 的 信息。然后在该登录请求的HTTP响应消息中 的头字段 Set-Cookie 里填入 sessionid 数据 添加输出响应头
vi Django_demo/mgr/sign_in_out.py
import requests,pprintpayload {username: root,password: 12345678
}response requests.post(http://127.0.0.1:8000/api/mgr/signin,datapayload)pprint.pprint(response.json())#输出相应头
for header, value in response.headers.items():print(f{header}: {value})
返回
{ret: 0}
Date: Fri, 20 Oct 2023 05:58:54 GMT
Server: WSGIServer/0.2 CPython/3.9.13
Content-Type: application/json
Content-Length: 10
Vary: Cookie
X-Content-Type-Options: nosniff
Referrer-Policy: same-origin
Cross-Origin-Opener-Policy: same-origin
Set-Cookie: sessionidotfwixmjgfngfc45n8k6efobiff4f3xs;
expiresFri, 03 Nov 2023 05:58:53 GMT; HttpOnly; Max-Age1209600; Path/; SameSiteLax#这一行
Set-Cookie: sessionidotfwixmjgfngfc45n8k6efobiff4f3xs; 根据http协议 这个Set-Cookie字段的意思就是 要求前端将其中的数据存入 cookie中。 并且随后访问该服务端的时候 在HTTP请求消息中必须带上 这些 cookie数据 cookie 通常就是存储在客户端浏览器的一些数据。 服务端可以通过http响应消息 要求 浏览器存储 一些数据。以后每次访问同一个网站服务 必须在HTTP请求中再带上这些cookie里面的数据。 cookie数据组成如下
sessionid6qu1cuk8cxvtf4w9rjxeppexh2izy0hh
usernamebyhy
favoritephone_laptop_watch 该用户的后续操作只要出发http请求, 都会在请求头的Cookie字段添加上面说的sessionID服务端接受到请求后只需要到session表中查看是否有该sessionID对应的记录这样就可以判断这个请求前面是已经登录过如果不是就可以拒绝服务重定向http请求到登录页面让用户登录 2、添加主页请求限制 在一开始的登录函数中我们调用了一个函数request.session[usertype] mgr 这行代码的作用 就是在登录认证后将 用户类型保存到session数据中 也就是存入前面数据库的那张图的 会话数据记录中Django 框架 会自动在 HTTP 响应消息头中 加入 类似刚才说的sessionid cookie Set-Cookie: sessionidotfwixmjgfngfc45n8k6efobiff4f3xs; 所以我们处理开通的/api/mgr 需要验证请求的cookie里面是否有sessionid并且检查session表看看是否存在session_key为该sessionid 的一条记录该记录的数据字典里面是否 包含了 usertype 为 mgr 的 数据我们可以把前面数据库增删改查视为我们的主页只需要从主页函数调用之前去做下检查即可 vi Django_demo/mgr/k8s.py
def dispatcher(request): # 将请求参数统一放入request 的 params 属性中方便后续处理# 根据session判断用户是否是登录的管理员用户if usertype not in request.session:return JsonResponse({ret: 302,msg: 未登录,redirect: /mgr/sign.html},status302)if request.session[usertype] ! mgr :return JsonResponse({ret: 302,msg: 用户非mgr类型,redirect: /mgr/sign.html} ,status302)...
3、测试访问
http://127.0.0.1:8000/api/mgr/customers/?actionlist_customer 可以看到尝试直接访问后端信息时因为找不到登录时携带的会话id则不运行登录 4、修改测试方法 我们修改一下请求方法先发送登录请求然后将相应头中的Set-Cookie取出在发起访问时在请求头中携带获取到的Cookie去请求就能正常访问了 vi main.py
import requests,pprintpayload {username: root,password: 12345678
}
#发送登录请求
response requests.post(http://127.0.0.1:8000/api/mgr/signin,datapayload)#拿到请求请求响应头中的值
set_cookie response.headers.get(Set-Cookie)
if set_cookie:# 将Set-Cookie字段的值添加到请求头中headers {Cookie: set_cookie}# 发送带有Cookie的新请求response requests.get(http://127.0.0.1:8000/api/mgr/customers/?actionlist_customer,headersheaders)pprint.pprint(response.json())
返回
{ret: 0,retlist: [{ClusterName: acp-r1-1,NodeSum: 100,PrometheusAddress: 192.168.1.1,id: 1},{ClusterName: 123123,NodeSum: 123123,PrometheusAddress: 123123,id: 2},{ClusterName: gfs-r3-1,NodeSum: 5000,PrometheusAddress: 192.168.1.21,id: 3}]}二、Token方案
1、session 缺点
1、性能问题 #验证请求是根据sessionid 到数据库中查找session表的#而数据库操作是服务端常见的性能瓶颈尤其是当用户量比较大的时候2、扩展性问题 #当系统用户特别多的时候后端处理请求的服务端通常是部署在多个节点上#但是多个节点都要访问session表这样就要求数据库服务能够被多个节点访问#不方便切分数据库以提高性能。 token 简单来说就是包含了数据信息和校验信息的数据包 Session 机制是把 数据信息比如session表放到 服务端服务端数据是客户无法篡改的从而保证验证的 可靠性而 token机制 数据信息 直接传给 客户端客户每次请求再携带过来给服务端。服务端无需查找数据库直接根据token里面的数据信息进行校验 但是上面的方法存在一个问题假设我是普通用户那天我获取到了一个vip用户的token拿是不是我就能访问vip用户的权限了为了防止 2、token机制说明
1、服务端先创建了一个密钥文件(secret key)2、用户登录成功后,服务端会将用户的信息数据和密钥一起进行一个哈希计算从而得到一个哈希值首先为了哈希算法保证一致性只能根据同样的数据源获取如果有人修改了用户信息成其他人的除非他也拿到了密钥, 不然他即使再用哈希算法计算也不会得到我们认证的token值, 所以这个哈希值就方便我们用来做数据校验当我们拿到了这个独一无二的哈希值后将哈希值和用户数据再做成一个字符串这个字符串也就被称之为tokentoken里面包含了用户数据和数据校验的哈希值服务端接受到请求后返回token值通常来说token是放在http响应头部中的, 具体那个头部字段没有规定可以自定义 3、用户的后续操作如果除非http api请求则会在请求消息中带上token值服务端接收到请求后会根据数据信息和密钥使用哈希再次生成哈希值如果用户修改了数据因为不知道密钥没有办法得到正确的新的哈希值那么服务端根据篡改后的数据和密钥得到的新的哈希值一定不同就知道数据被修改了如果客户端没有修改数据服务端根据原来的数据加上密钥得到的哈希值与保存在otken中的哈希值一对比校验通过后就知道没有被修改可以放心使用token中的用户数据了 三、实现token认证
1、安装库
pip install djangorestframework3.14.0
pip install djangorestframework-simplejwt 2、加载库配置
vi Django_demo/Django_demo/settings.py
INSTALLED_APPS [simpleui,django.contrib.admin,django.contrib.auth,django.contrib.contenttypes,django.contrib.sessions,django.contrib.messages,django.contrib.staticfiles,paas,mgr,#添加下面的配置rest_framework,rest_framework.authtoken,rest_framework_simplejwt.token_blacklist,
]
3、添加全局配置
vi Django_demo/Django_demo/settings.py
#找个空地方直接贴上,其中包含了认证方式和Token的过期时间等
REST_FRAMEWORK {DEFAULT_AUTHENTICATION_CLASSES: [rest_framework.authentication.TokenAuthentication, # 使用Token进行身份验证],DEFAULT_PERMISSION_CLASSES: [rest_framework.permissions.IsAuthenticated, # 需要进行身份验证的默认权限类],DEFAULT_THROTTLE_RATES: {user: 100/day, # 每个用户每天最多可以进行100次请求anon: 10/day # 匿名用户每天最多可以进行10次请求},DEFAULT_RENDERER_CLASSES: [rest_framework.renderers.JSONRenderer, # 默认使用JSON渲染器来渲染响应],DEFAULT_PARSER_CLASSES: [rest_framework.parsers.JSONParser, # 默认使用JSON解析器来解析请求数据],DEFAULT_METADATA_CLASS:rest_framework.metadata.SimpleMetadata, # 默认使用简单元数据类DEFAULT_VERSIONING_CLASS:rest_framework.versioning.URLPathVersioning, # 使用URL路径版本控制DEFAULT_FILTER_BACKENDS: [django_filters.rest_framework.DjangoFilterBackend # 默认使用Django Filter后端来进行过滤],DEFAULT_PAGINATION_CLASS:rest_framework.pagination.PageNumberPagination, # 默认的分页类为PageNumberPaginationPAGE_SIZE: 10, # 默认的每页返回的对象数量为10DEFAULT_THROTTLE_CLASSES: [rest_framework.throttling.AnonRateThrottle, # 默认使用匿名速率限制类rest_framework.throttling.UserRateThrottle # 默认使用用户速率限制类],DEFAULT_SCHEMA_CLASS: rest_framework.schemas.coreapi.AutoSchema, # 默认使用AutoSchema来生成API文档DEFAULT_CONTENT_NEGOTIATION_CLASS: rest_framework.negotiation.DefaultContentNegotiation, # 默认使用DefaultContentNegotiation进行内容协商COERCE_DECIMAL_TO_STRING: False, # 数字类型是否强制转换为字符串DATETIME_FORMAT: %Y-%m-%d %H:%M:%S, # 默认的日期时间格式DATETIME_INPUT_FORMATS: [%Y-%m-%d %H:%M:%S,%Y-%m-%d %H:%M,%Y-%m-%d,%Y%m%dT%H%M%S%fz], # 接受的日期时间输入格式的列表UNICODE_JSON: False, # 是否使用Unicode编码的JSON
}我们设置了TokenAuthentication作为默认的认证方式同时设置了IsAuthenticated权限表示只有已认证用户才能访问 4、同步库数据库操作
python manage.py makemigrations
python manage.py migrate
5、注释前面session认证 我们先将之前写的session判断给注释掉 vi Django_demo/mgr/k8s.py # 根据session判断用户是否是登录的管理员用户if usertype not in request.session:return JsonResponse({ret: 302,msg: 未登录,redirect: /mgr/sign.html},status302)if request.session[usertype] ! mgr :return JsonResponse({ret: 302,msg: 用户非mgr类型,redirect: /mgr/sign.html} ,status302) 此时我们访问查询应该就可以直接访问通了 http://127.0.0.1:8000/api/mgr/customers/?actionlist_customer 6、开启主页函数token验证
vi Django_demo/mgr/k8s.py
#导入模块
from rest_framework.authentication import TokenAuthentication # 导入TokenAuthentication类用于基于令牌进行身份验证
from rest_framework.permissions import IsAuthenticated # 导入IsAuthenticated类用于检查用户是否已通过身份验证的权限
from rest_framework.decorators import api_view, permission_classes, authentication_classes # 导入装饰器函数用于设置视图函数的身份验证和权限控制#添加装饰器
api_view([GET])
authentication_classes([TokenAuthentication]) # 使用TokenAuthentication类进行身份验证
permission_classes([IsAuthenticated]) # 要求用户已通过身份验证
def dispatcher(request): ...http://127.0.0.1:8000/api/mgr/customers/?actionlist_customer 我们需要让应用登录成功后获取到一个token值这里的token我们通过直接取用户 下面是说明代码不执行 from rest_framework.authtoken.models import Token # 导入 Token 模型用于创建和管理用户的 Token
from django.contrib.auth.models import User # 导入 User 模型用于获取用户对象# 获取用户
user User.objects.get(usernameroot) # 根据用户名获取用户对象# 创建 Token
token, created Token.objects.get_or_create(useruser) # 创建或获取与用户关联的 Token7、登录函数添加token获取 在登录函数登录成功之后添加一个获取登录用户token的值并跟随相应头返回token Django_demo/mgr/sign_in_out.py
def signin( request):userName request.POST.get(username)passWord request.POST.get(password)user authenticate(usernameuserName, passwordpassWord)if user is not None:if user.is_active:if user.is_superuser:login(request, user)request.session[usertype] mgr#添加返回用户的tokenfrom rest_framework.authtoken.models import Tokenfrom django.contrib.auth.models import Useruser User.objects.get(usernameuserName)# 创建或获取 Tokentoken, created Token.objects.get_or_create(useruser)return JsonResponse({token: str(token), ret: 0})else:return JsonResponse({ret: 1, msg: 请使用管理员账户登录})else:return JsonResponse({ret: 0, msg: 用户已经被禁用})# 否则就是用户名、密码有误else:return JsonResponse({ret: 1, msg: 用户名或者密码错误}) 8、测试检查是否返回token值
vi main.py
import requests,pprintpayload {username: root,password: 12345678
}
#发送登录请求
response requests.post(http://127.0.0.1:8000/api/mgr/signin,datapayload)
print(response.headers.get(Authorization))
返回
Token 1568e26d12af8a5a6489603763e662cf0c65c73a 9、携带token值请求主页
vi main.py
import requests,pprintpayload {username: root,password: 12345678
}
#发送登录请求
response requests.post(http://127.0.0.1:8000/api/mgr/signin,datapayload)
token response.headers.get(Authorization)#携带token请求
if token:# 将Set-Cookie字段的值添加到请求头中headers {Authorization: f{token}}response requests.get(http://127.0.0.1:8000/api/mgr/customers/?actionlist_customer,headersheaders)pprint.pprint(response.json())
返回
{ret: 0,retlist: [{ClusterName: acp-r1-1,NodeSum: 100,PrometheusAddress: 192.168.1.1,id: 1},{ClusterName: 123123,NodeSum: 123123,PrometheusAddress: 123123,id: 2},{ClusterName: gfs-r3-1,NodeSum: 5000,PrometheusAddress: 192.168.1.21,id: 3}]} 10、数据库内的token查询 牌Token在Django Rest Framework中是使用默认的Authentication模块提供的它默认存储在数据库中并且没有过期时间。这意味着一旦生成并分配给用户Token将一直有效直到被明确删除。 存储Token的数据库表是authtoken_token在数据库中的位置取决于你的Django项目的数据库配置。 默认情况下Token会与用户相关联并且将存储在Token模型的user字段中。每个用户可以有多个Token因此可以在这个模型上执行标准的查询操作 如果你希望对Token设置过期时间或者有更高级的需求你可以考虑使用第三方库如django-rest-framework-simplejwt。这个库提供了JWTJSON Web Token认证可以根据特定的配置设置Token的过期时间和其他功能。 四、session和token的区别详解
1、存储位置
TokenToken通常存储在服务器端的数据库中或者可以存储在客户端的cookie或本地存储中。每次发起请求时Token将通过请求头或请求参数进行传递。SessionSession通常存储在服务器端的数据库或缓存中。服务器将为每个会话分配一个唯一的Session ID并将Session ID存储在客户端的cookie中。客户端在发送请求时会自动携带Session ID。
2、无状态性
Token Token是无状态的服务器不需要在后端存储任何关于用户会话的状态信息。每个请求都包含所有必要的信息通常是在Token本身中来进行身份验证和授权。SessionSession是有状态的服务器需要在后端存储有关用户会话的状态信息。客户端的每个请求都需要携带Session ID服务器根据Session ID检索并验证对应的会话状态。
3、扩展性和跨域支持
Token 由于Token是无状态的因此易于扩展和支持跨域请求。服务器不需要存储每个用户的会话状态因此可以更好地支持负载均衡和分布式系统。Session 由于Session是有状态的需要在服务器端存储状态信息因此在处理大量并发请求或跨域请求时可能存在一些挑战。
4、过期和失效机制
Token Token可以通过设置过期时间来自动失效或者可以通过撤销Token的方式来手动使其失效。客户端需要负责在失效前获取新的Token。Session Session可以通过设置过期时间来自动失效但服务器也可以更主动地管理会话状态例如在用户注销或一段时间内无活动后自动销毁会话。
总结 Token适用于无状态、扩展性要求高、移动应用程序的场景而Session适用于有状态、需要跟踪用户会话状态的场景
