cookie与 session
一、cookie and session
HTTP协议是无状态的 也就是说 你每一次访问浏览器的话 浏览器是不认识你的 每一次访问都是独立的 ，浏览器是‘你虐他千百遍’ 转眼之间"他待你如初恋",他是不会受到前面请求响应情况直接影响，也不会直接影响后面的请求响应的情况，每一次请求都是全新的，对于状态这一词可以理解为 客户端和服务端在某次回话中产生的数据，那么无状态就是这些数据不会保存。但是有些会话的数据我们又是需要保存的，也就是要 "保持状态"，因此Cookie就是这样诞生的
1. Cookie
cookie具体指的就是一段小信息，他是服务器发出来储存在浏览器上的一组组键值对，下次访问服务器时浏览器会自动携带这些键值对，以便于服务器提取有用的信息
其工作原理：有服务器产生内容，浏览器收到请求后保存在本地：当浏览器再次访问时，浏览器会自动带上Cookie，这样子服务器可以通过cookie中的内容来判断这是 "谁"
设置cookie
obj = HttpResponse()
obj.set_cookie()
获取cookie
#第一种
request.COOKIES['key'] #不推荐使用
#第二章
request.COOKIE.get()
删除cookie
def logout(request):
rep = rediect('/login/')
rep.delete_cookie('user')
return rep
cookie版 登陆校验
from functools import wraps
def check_login(func):
@wraps(func)
def inner(request,*args,**kwargs):
if request.COOKIES.get('username'):
return func(request,*args,**kwargs)
else:
next_url = request.path_info
return redirect('/login/?next=%s'%next_url)
return inner
def login(request):
if request.method == "GET":
return render(request,'login.html')
if request.method== "POST":
username = request.POST.get('username')
password = request.POST.get('password')
if username =='luodaoqi' and password =='123':
old_path = request.GET.get('next')
if old_path:
obj = redirect(old_path)
else:
obj = redirect('/index/')
obj.set_cookie('username','password')
return obj
return render(request,'login.html')
二、session
cookie 虽然在一定程度上解决了“保持状态”的需求，但是由于Cookie本身最大支持4096字节，以及Cookie本身保存在客户端，可能被拦截或窃取，因此就需要有一种新东西，他能支持更多的字节，并且他保存在服务器，有较高的安全性。
这就是session
获取session
#第一种
request.session['key']
#第二种
request.session.get('key',None)
'''
1.django内部自动生成了随机的字符串
2.在django_session表中存入数据
session_key session_data date
随机字符串1 数据1 ...
随机字符串2 数据2 ...
随机字符串3 数据3 ...
3.将产生的随机字符串发送给浏览器 让浏览器保存到cookie中
sessionid:随机字符串
'''
设置session
request.session['key']=xxx
request.session.setdefault('key',xxx)#存在就不设置
'''
1.浏览器发送cookie到django后段之后 django会自动获取到cookie值
2.拿着随机字符串去django session表中比对 是否有对应的数据
3.如果比对上了 就讲随机字符串所对应的数据 去除赋值给request.session
如果比对不上 那么request.session就是 空
'''
#django session表对于同一个浏览器只会有一条记录 不同的有多个记录
删除session
request.session.delete() #只会删除服务端的session
request.session.flush() #浏览器 和服务端的全部删除
设置session 超时时间
request.session.set_expiry(value多种配置)
数字
0
不写
时间格式
Django中间件(*****)
用户访问频率限制
用户是否黑名单 白名单
所有用户登陆校验
只要涉及到网址全局的功能 你就应该考虑使用中间件
django中间件暴露呗程序员五个可以自定义的方法(五个方法都是在特定条件下触发的)
-
新建一个文件夹 里面新建一个任意名称的PY文件
里面写类 固定继承
from django.utils.deprecation import MiddlewareMixin
class MyMiddle(MiddlewareMixin):2.去配置文件注册到中间件配置中
你需要手写字符串的路径
'app01.mymiddleware.myaabb.MyMiddle1'
跨站请求伪造（csrf） 钓鱼网站
就类似于你搭建了一个跟银行一模一样的web页面
用户在你的网站转账的时候输入用户名 密码 对方账户
银行里面的钱确实少了 但是发现收款人变了
最简单的原理
你写的form表单中 用户的用户名 密码都会真实的提交给银行后台
但是收款人的账户却不是用户填的 你暴露给用户的是一个没有name属性的input框
你自己提前写好了一个隐藏的带有name和value的input框
解决钓鱼网站的策略
只要是用户想要提交post请求的页面 我在返回给用户的时候就提前设置好一个随机字符串
当用户提交post请求的时候 我会自动先取查找是否有该随机字符串
如果有 正常提交
如果没有 直接报403
form表单
你在写的时候只需要加上一个
{% csrf_token %}
ajax
第一种 自己再页面上先通过{% csrf_token %}获取到随机字符串 然后利用标签查找
data:{'username':'jason','csrfmiddlewaretoken':$('[name="csrfmiddlewaretoken"]').val()},
第二种
data:{'username':'jason','csrfmiddlewaretoken':'{{ csrf_token }}'},
第三种
拷贝js文件
装饰器
csrf_exempt 只有两种装饰的方式
from django.views.decorators.csrf import csrf_exempt, csrf_protect
from django.utils.decorators import method_decorator
# 第一种
# @method_decorator(csrf_exempt,name='dispatch')
class MyCsrf(View):
# 第二种
@method_decorator(csrf_exempt)
def dispatch(self, request, *args, **kwargs):
return super().dispatch(request,*args,**kwargs)
def get(self,request):
return HttpResponse('hahaha')
除了csrf_exempt之外 所有的其他装饰器 在CBV上面都有三种方式
@method_decorator(csrf_protect,name='post')
class MyCsrf(View):
@method_decorator(csrf_protect)
def dispatch(self, request, *args, **kwargs):
return super().dispatch(request,*args,**kwargs)
def get(self,request):
return HttpResponse('hahaha')
@method_decorator(csrf_protect)
def post(self,request):
return HttpResponse('post')
