(列出一个连接:该连接详细介绍了django session的基础用法,有兴趣的看:
https://www.cnblogs.com/zhaof/p/6281468.html
关于上述连接补充一点,request.session是一个既管理db中全部session也处理session_key对应
的当前session的一个对象,当前session的相关数据都存储在request.session._session中,有兴趣可以参看源码/site-packages/django/contrib/session/backends/db.py)
我们都知道session对应的是用户信息,django为登录的用户创建session的过程如下:
1、用户首次打开登录页面时,由于之前没有登录过,所以request头中不包含cookie字段
登录页面返回时会让用户设置csrf token
2、用户输入用户名和密码后,点击登录:
此时的POST请求的request头中会携带csrfmiddlewaretoken,而cookie中携带的是CSRF TOKEN(注意这两个token值不相同)。django会在后台对这两个token进行相同的解密算法,事实上这两个token原子与一个相同的值,所以在解密后二者的值是相等的,此时二者比较成功则验证通过,同时在回复的response header中设置新的csrftoken(此处这两个token的详细解密解密请参考/site-packages/django/middleware/csrf.py的源码)。
部分源码如下:
# Check non-cookie token for match.
request_csrf_token = ""
if request.method == "POST":
try:
request_csrf_token = request.POST.get('csrfmiddlewaretoken', '')
except IOError:
# Handle a broken connection before we've completed reading
# the POST data. process_view shouldn't raise any
# exceptions, so we'll ignore and serve the user a 403
# (assuming they're still listening, which they probably
# aren't because of the error).
pass
if request_csrf_token == "":
# Fall back to X-CSRFToken, to make things easier for AJAX,
# and possible for PUT/DELETE.
request_csrf_token = request.META.get(settings.CSRF_HEADER_NAME, '')
request_csrf_token = _sanitize_token(request_csrf_token)
if not _compare_salted_tokens(request_csrf_token, csrf_token):
return self._reject(request, REASON_BAD_TOKEN)
3、用户登录成功后,只要不执行logout,sessionid一直存放在cookie中,用户在访问后续的接口时就不需要再此登录了