当前位置:   article > 正文

Django cookie&session - 让浏览器记住你哦_django session使用

django session使用

cookie和session简介

HTTP协议是无状态的,这意味这所有的客户端或者浏览器朝服务端发请求,服务端是不会记住客户端是谁,没办法保存用户的登录信息。

随之WEB的发展,出现了网上商城之类购物网站,这类网站的一个需求是记住当前用户是谁,并且需要记住用户的登录状态(避免每次请求页面都重新登录)。

为了解决这个需求,出现了很多总解决办法。其中最有效的一个办法是:当用户第一次登录成功后,将用户的登录信息(用户名和密码)返回给用户的浏览器,让浏览器将登录信息保存在本地浏览器(cookie);之后用户再次访问该网站时,浏览器会携带之前保存的该网站的登录信息,这样服务端获取登录信息之后自动登录验证。

但是这种方式存在很大的安全隐患:容易泄露用户的登录信息;后来又出现了优化的解决办法。

新的解决办法是:当用户初次登录成功后,服务端会产生一个随机字符串,该字符串保存在服务端(session),保存成键值对的形式。同时将该字符串交由客户端浏览器保存。之后再访问服务端的时候,浏览器都会带着这个随机字符串,服务端去数据库中匹配是否又这个随机字符串对应的用户信息;匹配成功则自动登录。

其实,如果截获到该随机字符串,那么就可以冒充当前用户,其实还是有安全隐患的。所以应了那句话:在web领域没有绝对的安全也没有绝对的不安全

这就是cookie和session的出现历程。

cookie

虽然cookie是服务端告诉客户端浏览器需要保存内容,但是客户端浏览器可以选择拒绝保存;如果将浏览器设置为禁止保存服务端的cookie,那么只要是需要记录用户状态的网站登陆功能都无法使用了。

服务端保存在客户端浏览器的信息都可以称之为cookie,在客户端浏览器中cookie的表现形式一般都是key:value键值对的形式。在浏览器的调试模式中打开application就可以看见cookie。

django中操作cookie

django的视图函数的返回值一般有三种,分别是HttpResponse对象、render()redirect(),本质上都是返回的HttpResponse对象,因此我们可以直接返回也可以现将对象用变量保存下来再返回,如果想要在django中操作cookie的话就必须利用中间变量。

  1. # 不使用cookie
  2. return HttpResponse()
  3. return render()
  4. return redirect()
  5. # 使用cookie
  6. obj = HttpResponse()
  7. 操作cookie
  8. return obj

如何设置cookie和获取cookie以及删除cookie呢?

  1. # 当用户访问服务端时,为客户端浏览器设置cookie,客户端浏览器保存该cookie
  2. obj.set_cookie(key, value)
  3. # 当用户访问需要登录才能进入的页面时,服务端需要获取客户端浏览器携带的cookie,进行校验
  4. obj.COOKIES.get(key)
  5. # 删除用户浏览器上之前设置的usercookie值
  6. obj.delete_cookie(key)

有一些网站每过一段时间就会让你重新登录,就是因为设置了cookie的过期时间,在django中也可以为cookie设置过期时间:

  1. obj.set_cookie(key, value, max_age=3)
  2. obj.set_cookie(key, value, expires=3)
  3. # 两个参数都是设置超时时间的,并且都是以秒为单位;需要注意的是,针对IE浏览器需要使用expires

cookie版登录和注销

需求大概就是使用cookie完成登录和注销的功能,并且通过装饰器实现不登录就无法使用除注册外的功能,未登录时访问功能页面直接跳转到登录页面,登录成功之后再访问想要访问的页面。

首先是登陆装饰器,装饰器可以放在项目根目录下的utils目录(自己创建)中。

  1. # utils/login_auth
  2. from functools import wraps
  3. from django.shortcuts import redirect
  4. def login_auth(func):
  5. @wraps(func)
  6. def inner(request, *args, **kwargs):
  7. target_url = request.get_full_path() # 获取用户想要访问的url
  8. if request.COOKIES.get('is_login'):
  9. res = func(request, *args, **kwargs)
  10. return res
  11. else:
  12. return redirect(f'/login/?next={target_url}') # 设置登录后跳转的页面url
  13. return inner

下面是视图函数:

  1. # views.py
  2. from utils.login_auth import login_auth
  3. # 登录页面
  4. def login(request):
  5. info = {'msg':''}
  6. # 获取用户上一次想要访问的页面
  7. tag_url = request.GET.get('next')
  8. if request.method == 'POST':
  9. username = request.POST.get('username')
  10. password = request.POST.get('password')
  11. if username == 'python' and password == '123':
  12. if tag_url:
  13. obj = redirect(tag_url)
  14. else:
  15. # 不能直接返回redirect,因为直接返回是无法保存cookie的,必须使用obj返回,才能记录状态,浏览器客户端才会保存
  16. obj = redirect('/home/')
  17. # max_age就是设置cookie的有效期,单位是秒,当达到了有效期后,浏览器客户端会自动删除本地的cookie信息
  18. obj.set_cookie('is_login', 'this_user_has_been_logined', max_age=10000)
  19. return obj
  20. else:
  21. info['msg'] = '帐号密码错误'
  22. return render(request,'login.html',locals())
  23. # 退出登录
  24. @login_auth
  25. def logout(request):
  26. response_obj = redirect('login')
  27. response_obj.delete_cookie('is_login')
  28. return response_obj
  29. # 主页
  30. @auth
  31. def home(request):
  32. return HttpResponse('我是home页面')

session

Cookie虽然在一定程度上解决了“保持状态”的需求,但是由于Cookie本身最大支持4096字节,以及Cookie本身保存在客户端,可能被拦截或窃取。因此就需要有一种新的东西,它能支持更多的字节,并且保存在服务器,有较高的安全性。这就是Session。

问题来了,基于HTTP协议的无状态特征,服务器根本就不知道访问者是“谁”。那么上述的Cookie就起到桥接的作用。

我们可以给每个客户端的Cookie分配一个唯一的id,这样用户在访问时,通过Cookie,服务器就知道来的人是“谁”。然后我们再根据不同的Cookie的id,在服务器上保存一段时间的私密资料,如“账号密码”等等。

总结而言:Cookie弥补了HTTP无状态的不足,让服务器知道来的人是“谁”;但是Cookie以文本的形式保存在本地,自身安全性较差;所以我们就通过Cookie识别不同的用户,对应的在Session里保存私密的信息以及超过4096字节的文本。

另外,上述所说的Cookie和Session其实是共通性的东西,不限于语言和框架。

django中操作session

django中session的操作通过request对象下的session完成,它类似一个字典结构,操作方式和字典的操作非常类似。session中的数据是保存在服务端的数据库django_session表中,给客户端返回的是一个随机字符串,django默认session的过期时间是14天,可以认为修改它。django_session表中的数据条数是取决于浏览器的,同一个计算机上(IP地址)同一个浏览器只会有一条数据生效。主要是为了节省服务端数据库资源。

  1. # 获取、设置、删除Session中数据
  2. request.session['k1'] # 拿到'k1'对应的value
  3. request.session.get('k1', None)
  4. request.session['k1'] = 123
  5. request.session.setdefault('k1',123) # 存在则不设置
  6. del request.session['k1']
  7. # 所有 键、值、键值对
  8. request.session.keys()
  9. request.session.values()
  10. request.session.items()
  11. request.session.iterkeys()
  12. request.session.itervalues()
  13. request.session.iteritems()
  14. # 会话session的key
  15. request.session.session_key # 随机字符串ryl3jza580roxfntx8wittr0vykvmi5h
  16. # 将所有Session失效日期小于当前日期的数据删除
  17. request.session.clear_expired()
  18. # 检查会话session的key在数据库中是否存在
  19. request.session.exists("session_key")
  20. # 删除当前会话的所有Session数据
  21. request.session.delete() # 只删服务端的 客户端的不删
  22. request.session.flush() # 浏览器和服务端都清空(推荐使用)
  23. 这用于确保前面的会话数据不可以再次被用户的浏览器访问
  24. 例如,django.contrib.auth.logout() 函数中就会调用它。
  25. # 设置会话Session和Cookie的超时时间
  26. request.session.set_expiry(value)
  27. * 如果value是个整数,session会在这些秒数后失效。
  28. * 如果value是个datatime或timedelta,session就会在这个时间后失效。
  29. * 如果value是0,用户关闭浏览器session就会失效。
  30. * 如果value是None,session会依赖全局session失效策略。

session内部发生的事情

当使用request.session['is_login'] = 'login'时会发生下述事情:

  1. 1.django内部会自动帮你生成一个随机字符串
  2. 2.django内部自动将随机字符串和对应的数据存储到django_session表中
  3. 2.1先在内存中产生操作数据的缓存
  4. 2.2在响应结果django中间件的时候才真正的操作数据库
  5. 2.1先在内存中产生操作数据的缓存
  6. 2.2在响应结果django中间件的时候才真正的操作数据库
  7. django_session表内存储格式
  8. session_key session_data expire_date
  9. 随机字符串1 对应数据密文 过期时间
  10. 随机字符串2 对应数据密文 过期时间
  11. ......
  12. 3.将产生的随机字符串返回给客户端浏览器保存

用画图来来表示过程如下:

使用request.get['is_login']时发生的事情:

  1. 1.自动从浏览器请求中获取sessionid对应的随机字符串
  2. 2.拿着该随机字符串去django_session表中查找对应的数据
  3. 3.如果比对上了 则将对应的数据取出并以字典的形式封装到request.session中
  4. 如果比对不上 则request.session.get()返回的是None

CBV添加装饰器

实现登陆之后才能访问其他页面的需求在使用FBV的情况下,只需要为视图函数添加装饰器即可,那么CBV模式的视图类又如何实现此需求呢?这里介绍三种添加装饰器的方式,在这之前需要明确一点,CBV中django不建议直接给类的方法添加装饰器,不论装饰器是否生效。

CBV遇到需要加装饰器时,需要先导入from django.utils.decorators import method_decorator,在然后在指定方法上加@method_decorator(method_name),如果加在类上,还需要提供装饰的名字:@method_decorator(decorator_name, method_name),下面是添加装饰器的方式:

给方法加装饰器

  1. from django.views import View
  2. from django.utils.decorators import method_decorator
  3. class MyLogin(View):
  4. @method_decorator(login_auth) # 方式1:给get方法添加装饰器
  5. def get(self,request):
  6. return HttpResponse("get请求")
  7. def post(self,request):
  8. return HttpResponse('post请求')
  9. # 优点:简单直接
  10. # 缺点:多个方法时,需要多次添加装饰器

给类加装饰器

  1. from django.views import View
  2. from django.utils.decorators import method_decorator
  3. @method_decorator(login_auth, name='get') # 同时提供装饰器和被装饰的方法
  4. @method_decorator(login_auth, name='post') # 支持装饰器多个叠加
  5. class MyLogin(View):
  6. def get(self,request):
  7. return HttpResponse("get请求")
  8. def post(self,request):
  9. return HttpResponse('post请求')
  10. # 优点:给不同的方法,添加不同的装饰器

通过dispatch方法

  1. from django.views import View
  2. from django.utils.decorators import method_decorator
  3. class MyLogin(View):
  4. @method_decorator(login_auth) # 方式3:它会直接作用于当前类里面的所有的方法
  5. def dispatch(self, request, *args, **kwargs):
  6. return super().dispatch(request,*args,**kwargs)
  7. def get(self,request):
  8. return HttpResponse("get请求")
  9. def post(self,request):
  10. return HttpResponse('post请求')
  11. # 优点:一次性给所有方法添加装饰器(某些特殊装饰器只能加在dispatch上,例如csrf认证)
  12. # 缺点:灵活性差

最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:

这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你! 

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/从前慢现在也慢/article/detail/559590
推荐阅读
相关标签
  

闽ICP备14008679号