hello~Django2
Middleware
中间件是一个钩子框架，是介于request与response处理之间的一道处理过程，它们可以介入Django 的请求和响应处理过程。它是一个轻量级、底层的“插件”系统，用于在全局修改Django 的输入或输出。
每个中间件组件负责完成某个特定的功能。例如，Django 包含的一个中间件组件AuthenticationMiddleware ，它使用会话将用户和请求关联起来。
我们从浏览器发出一个请求 Request，得到一个响应后的内容 HttpResponse ，这个请求传递到 Django的过程如下：
激活中间件
要激活一个中间件组件，需要把它添加到Django 配置文件中的MIDDLEWARE_CLASSES 元组中。
在MIDDLEWARE_CLASSES中，每一个中间件组件用字符串的方式描述：一个完整的Python全路径加上中间件的类名称。例如，使用 django-admin startproject创建工程的时候生成的默认值：
|
1
2
3
4
5
6
7
8
9
10
|
MIDDLEWARE_CLASSES = ( 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.auth.middleware.SessionAuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'django.middleware.security.SecurityMiddleware',) |
Django的程序中，中间件不是必需的 —— 只要你喜欢，MIDDLEWARE_CLASSES可以为空 —— 但是强烈推荐你至少使用CommonMiddleware。
MIDDLEWARE_CLASSES中的顺序非常重要，因为一个中间件可能依赖于另外一个。例如，AuthenticationMiddleware在会话中储存已认证的用户。所以它必须在SessionMiddleware之后运行。一些关于Django中间件类的顺序的常见提示，请见中间件排序。
钩子和应用的顺序
在请求阶段中，调用视图之前，Django会按照MIDDLEWARE_CLASSES中定义的顺序自顶向下应用中间件。会用到两个钩子：
在响应阶段中，调用视图之后，中间件会按照相反的顺序应用，自底向上。会用到三个钩子：
- process_exception() （仅当视图抛出异常的时候）
- process_template_response() （仅用于模板响应）
- process_response()
如果你愿意的话，你可以把它想象成一颗洋葱：每个中间件都是包裹视图的一层“皮”。
每个钩子的行为接下来会描述。
编写自己的中间件
#---------------------------------------------views.py def hello(req): print('views') return HttpResponse('ok') #---------------------------------------------settings.py MIDDLEWARE_CLASSES = [ 'mymiddle_ware.mymiddle.MiddleTest', 'mymiddle_ware.mymiddle.MiddleTest2', 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.auth.middleware.SessionAuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', ] #---------------------------------------------mymiddle.py from django.shortcuts import render,HttpResponse class MiddleTest(object): def process_request(self,req): print('process_request....') # return HttpResponse('你好') #越过其它中间件和views,去经过response系列转运 def process_response(self,req,res): print('process_response....') return res ##res即views返回的 HttpResponse('ok')对象 class MiddleTest2(object): def process_request(self,req): print('process_request2....') def process_response(self,req,res): print('process_response2....') return res #res即views返回的 HttpResponse('ok')对象 def process_exception(self,request, exception): print('exception',exception) return HttpResponse(exception)
编写自己的中间件很容易的。每个中间件组件是一个独立的Python 类，你可以定义下面这些方法中的一个或多个：
process_request
request是一个HttpRequest 对象。
在Django决定执行哪个视图之前，process_request()会在每个请求上调用。
它应该返回一个None 或一个HttpResponse对象。如果返回None，Django会继续处理这个请求，执行其它process_request()中间件，然后process_view()中间件，最后是对应的视图。如果它返回一个HttpResponse对象，Django 就不用再去调用其它的request、view 或exception 中间件，或对应的视图；它将对HttpResponse 运用响应阶段的中间件，并返回结果。
process_view
request是一个HttpRequest对象。view_func是 Django会调用的一个Python的函数。（它是一个真实的函数对象，不是函数的字符名称。) view_args是一个会被传递到视图的位置参数列表，而view_kwargs 是一个会被传递到视图的关键字参数字典。 view_args和 view_kwargs 都不包括第一个视图参数(request)。
process_view()会在Django 调用视图之前被调用。
它将返回None 或一个HttpResponse 对象。如果返回None，Django 将会继续处理这个请求，执行其它的process_view() 中间件，然后调用对应的视图。如果返回一个HttpResponse对象，Django 就不用再去调用其它的view 或exception 中间件，或对应的视图；它将对HttpResponse 运用响应阶段的中间件，并返回结果。
注意
在中间件内部，从process_request 或process_view 中访问request.POST 或request.REQUEST 将阻碍该中间件之后的所有视图无法修改请求的上传处理程序，一般情况下要避免这样使用。
类CsrfViewMiddleware可以被认为是个例外，因为它提供csrf_exempt() 和csrf_protect()两个装饰器，允许视图显式控制在哪个点需要开启CSRF验证。
process_template_response
process_template_response(request, response)
request是一个HttpRequest对象。response是一个TemplateResponse对象（或等价的对象），由Django视图或者中间件返回。
如果响应的实例有render()方法，process_template_response()在视图刚好执行完毕之后被调用，这表明了它是一个TemplateResponse对象（或等价的对象）。
这个方法必须返回一个实现了render方法的响应对象。它可以修改给定的response对象，通过修改 response.template_name和response.context_data或者它可以创建一个全新的 TemplateResponse或等价的对象。
你不需要显式渲染响应 —— 一旦所有的模板响应中间件被调用，响应会自动被渲染。
在一个响应的处理期间，中间件以相反的顺序运行，这包括process_template_response()。
process_response
process_response(request, response)
request是一个HttpRequest对象。response是Django视图或者中间件返回的HttpResponse或者StreamingHttpResponse对象。
process_response()在所有响应返回浏览器之前被调用。
这个方法必须返回HttpResponse或者StreamingHttpResponse对象。它可以改变已有的response，或者创建并返回新的HttpResponse或StreamingHttpResponse对象。
不像 process_request()和process_view()方法，即使同一个中间件类中的process_request()和process_view()方法会因为前面的一个中间件返回HttpResponse而被跳过，process_response()方法总是会被调用。特别是，这意味着你的process_response()方法不能依赖于process_request()方法中的设置。
最后，记住在响应阶段中，中间件以相反的顺序被应用，自底向上。意思是定义在MIDDLEWARE_CLASSES最底下的类会最先被运行。
处理流式响应
不像HttpResponse，StreamingHttpResponse并没有content属性。所以，中间件再也不能假设所有响应都带有content属性。如果它们需要访问内容，他们必须测试是否为流式响应，并相应地调整自己的行为。
|
1
2
3
4
|
if response.streaming: response.streaming_content = wrap_streaming_content(response.streaming_content)else: response.content = alter_content(response.content) |
注意
我们需要假设streaming_content可能会大到在内存中无法容纳。响应中间件可能会把它封装在新的生成器中，但是一定不要销毁它。封装一般会实现成这样：
|
1
2
3
|
def wrap_streaming_content(content): for chunk in content: yield alter_content(chunk) |
process_exception
request是一个HttpRequest对象。exception是一个被视图中的方法抛出来的 Exception对象。
当一个视图抛出异常时，Django会调用process_exception()来处理。process_exception()应该返回一个None或者一个HttpResponse对象。如果它返回一个HttpResponse对象，模型响应和响应中间件会被应用，响应结果会返回给浏览器。否则， 默认的异常处理机制将会被触发。
再次提醒，在处理响应期间，中间件的执行顺序是倒序执行的，这包括process_exception。如果一个异常处理的中间件返回了一个响应，那这个中间件上面的中间件都将不会被调用。
__init__
大多数的中间件类都不需要一个初始化方法，因为中间件的类定义仅仅是为process_*提供一个占位符。如果你确实需要一个全局的状态那就可以通过__init__来加载。然后要铭记如下两个警告： Django初始化你的中间件无需任何参数，因此不要定义一个有参数的__init__方法。 不像process_* 对每个请求都要调用，__init__ 只会被调用一次，就是在Web 服务器响应第一个请求的时候。 标记中间件不被使用¶ 有时在运行时决定是否一个中间件需要被加载是很有用的。 在这种情况下，你的中间件中的 __init__方法可以抛出一个django.core.exceptions.MiddlewareNotUsed异常。Django会从中间件处理过程中移除这部分中间件，并且当DEBUG为True的时候在django.request记录器中记录调试信息。
应用
from django.shortcuts import render,HttpResponse #项目 abcd 文件名 abcd/middleware.py class BlockedIpMiddleware(object): def process_request(self, request): if request.META['REMOTE_ADDR'] in getattr(settings, "BLOCKED_IPS", []): return HttpResponse('<h1>Forbbiden</h1>') #----settings.py MIDDLEWARE_CLASSES = ( 'abcd.middleware.BlockedIpMiddleware', #...其它的中间件 )
cache
Django 官方关于cache的介绍：https://docs.djangoproject.com/en/dev/topics/cache/
Django 是动态网站，一般来说需要实时地生成访问的网页，展示给访问者，这样，内容可以随时变化，但是从数据库读多次把所需要的数据取出来，要比从内存或者硬盘等一次读出来 付出的成本大很多。
缓存系统工作原理：
对于给定的网址，尝试从缓存中找到网址，如果页面在缓存中，直接返回缓存的页面，如果缓存中没有，一系列操作（比如查数据库）后，保存生成的页面内容到缓存系统以供下一次使用，然后返回生成的页面内容。
一 配置
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
# Django settings 中 cache 默认为{ 'default': { 'BACKEND': 'django.core.cache.backends.locmem.LocMemCache', }}# 也就是默认利用本地的内存来当缓存，速度很快。当然可能出来内存不够用的情况，其它的一些内建可用的 Backends 有'django.core.cache.backends.locmem.LocMemCache''django.core.cache.backends.dummy.DummyCache''django.core.cache.backends.db.DatabaseCache''django.core.cache.backends.filebased.FileBasedCache''django.core.cache.backends.memcached.MemcachedCache''django.core.cache.backends.memcached.PyLibMCCache' |
DummyCache
# 此为开始调试用，实际内部不做任何操作 # 配置： CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.dummy.DummyCache', # 引擎 'TIMEOUT': 300, # 缓存超时时间（默认300，None表示永不过期，0表示立即过期） 'OPTIONS':{ 'MAX_ENTRIES': 300, # 最大缓存个数（默认300） 'CULL_FREQUENCY': 3, # 缓存到达最大个数之后，剔除缓存个数的比例，即：1/CULL_FREQUENCY（默认3） }, 'KEY_PREFIX': '', # 缓存key的前缀（默认空） 'VERSION': 1, # 缓存key的版本（默认1） 'KEY_FUNCTION' 函数名 # 生成key的函数（默认函数会生成为：【前缀:版本:key】） } } # 自定义key def default_key_func(key, key_prefix, version): """ Default function to generate keys. Constructs the key used by all other methods. By default it prepends the `key_prefix'. KEY_FUNCTION can be used to specify an alternate function with custom key making behavior. """ return '%s:%s:%s' % (key_prefix, version, key) def get_key_func(key_func): """ Function to decide which key function to use. Defaults to ``default_key_func``. """ if key_func is not None: if callable(key_func): return key_func else: return import_string(key_func) return default_key_func
DatabaseCache
# 利用数据库来缓存，利用命令创建相应的表：python manage.py createcachetable cache_table_name CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.db.DatabaseCache', 'LOCATION': 'cache_table_name', 'TIMEOUT': 600, 'OPTIONS': { 'MAX_ENTRIES': 2000 } } }
FileBasedCache
# 利用文件系统来缓存： CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache', 'LOCATION': '/var/tmp/django_cache', 'TIMEOUT': 600, 'OPTIONS': { 'MAX_ENTRIES': 1000 } } }
MemcachedCache
# 此缓存使用python-memcached模块连接memcache CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache', 'LOCATION': '127.0.0.1:11211', } } CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache', 'LOCATION': 'unix:/tmp/memcached.sock', } } CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache', 'LOCATION': [ '172.19.26.240:11211', '172.19.26.242:11211', ] } }
PyLibMCCache
# 此缓存使用pylibmc模块连接memcache CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache', 'LOCATION': '127.0.0.1:11211', } } CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache', 'LOCATION': '/tmp/memcached.sock', } } CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache', 'LOCATION': [ '172.19.26.240:11211', '172.19.26.242:11211', ] } }
二 应用
1 全站使用
使用中间件，经过一系列的认证等操作，如果内容在缓存中存在，则使用FetchFromCacheMiddleware获取内容并返回给用户，当返回给用户之前，判断缓存中是否已经存在，如果不存在则UpdateCacheMiddleware会将缓存保存至缓存，从而实现全站缓存 MIDDLEWARE = [ 'django.middleware.cache.UpdateCacheMiddleware', # 其他中间件... 'django.middleware.cache.FetchFromCacheMiddleware', ] CACHE_MIDDLEWARE_ALIAS = "" CACHE_MIDDLEWARE_SECONDS = "" CACHE_MIDDLEWARE_KEY_PREFIX = ""
2 单独视图缓存
方式一： from django.views.decorators.cache import cache_page @cache_page(60 * 15) def my_view(request): ... 方式二： from django.views.decorators.cache import cache_page urlpatterns = [ url(r'^foo/([0-9]{1,2})/$', cache_page(60 * 15)(my_view)), ]
3 模版局部视图使用
1. 引入TemplateTag {% load cache %} 2. 使用缓存 {% cache 5000 缓存key %} 缓存内容 {% endcache %}
# 一般来说我们用 Django 来搭建一个网站，要用到数据库等。 from django.shortcuts import render def index(request): # 读取数据库等 并渲染到网页 # 数据库获取的结果保存到 queryset 中 return render(request, 'index.html', {'queryset':queryset}) # 像这样每次访问都要读取数据库，一般的小网站没什么问题，当访问量非常大的时候，就会有很多次的数据库查询，肯定会造成访问速度变慢，服务器资源占用较多等问题。 #------------------------------------------ #------------------------------------------ from django.shortcuts import render from django.views.decorators.cache import cache_page @cache_page(60 * 15) # 秒数，这里指缓存 15 分钟，不直接写900是为了提高可读性 def index(request): # 读取数据库等 并渲染到网页 return render(request, 'index.html', {'queryset':queryset}) # 当使用了cache后，访问情况变成了如下： # 访问一个网址时, 尝试从 cache 中找有没有缓存内容 # 如果网页在缓存中显示缓存内容，否则生成访问的页面，保存在缓存中以便下次使用，显示缓存的页面。 # given a URL, try finding that page in the cache # if the page is in the cache: # return the cached page # else: # generate the page # save the generated page in the cache (for next time) # return the generated page # Memcached 是目前 Django 可用的最快的缓存
Cookie & Session
1、cookie不属于http协议范围，由于http协议无法保持状态，但实际情况，我们却又需要“保持状态”，因此cookie就是在这样一个场景下诞生。
cookie的工作原理是：由服务器产生内容，浏览器收到请求后保存在本地；当浏览器再次访问时，浏览器会自动带上cookie，这样服务器就能通过cookie的内容来判断这个是“谁”了。
2、cookie虽然在一定程度上解决了“保持状态”的需求，但是由于cookie本身最大支持4096字节，以及cookie本身保存在客户端，可能被拦截或窃取，因此就需要有一种新的东西，它能支持更多的字节，并且他保存在服务器，有较高的安全性。这就是session。
问题来了，基于http协议的无状态特征，服务器根本就不知道访问者是“谁”。那么上述的cookie就起到桥接的作用。
我们可以给每个客户端的cookie分配一个唯一的id，这样用户在访问时，通过cookie，服务器就知道来的人是“谁”。然后我们再根据不同的cookie的id，在服务器上保存一段时间的私密资料，如“账号密码”等等。
3、总结而言：cookie弥补了http无状态的不足，让服务器知道来的人是“谁”；但是cookie以文本的形式保存在本地，自身安全性较差；所以我们就通过cookie识别不同的用户，对应的在session里保存私密的信息以及超过4096字节的文本。
4、另外，上述所说的cookie和session其实是共通性的东西，不限于语言和框架
前几节的介绍中我们已经有能力制作一个登陆页面，在验证了用户名和密码的正确性后跳转到后台的页面。但是测试后也发现，如果绕过登陆页面。直接输入后台的url地址也可以直接访问的。这个显然是不合理的。其实我们缺失的就是cookie和session配合的验证。有了这个验证过程，我们就可以实现和其他网站一样必须登录才能进入后台页面了。
先说一下这种认证的机制。每当我们使用一款浏览器访问一个登陆页面的时候，一旦我们通过了认证。服务器端就会发送一组随机唯一的字符串（假设是123abc）到浏览器端，这个被存储在浏览端的东西就叫cookie。而服务器端也会自己存储一下用户当前的状态，比如login=true，username=hahaha之类的用户信息。但是这种存储是以字典形式存储的，字典的唯一key就是刚才发给用户的唯一的cookie值。那么如果在服务器端查看session信息的话，理论上就会看到如下样子的字典
{'123abc':{'login':true,'username:hahaha'}}
因为每个cookie都是唯一的，所以我们在电脑上换个浏览器再登陆同一个网站也需要再次验证。那么为什么说我们只是理论上看到这样子的字典呢？因为处于安全性的考虑，其实对于上面那个大字典不光key值123abc是被加密的，value值{'login':true,'username:hahaha'}在服务器端也是一样被加密的。所以我们服务器上就算打开session信息看到的也是类似与以下样子的东西
{'123abc':dasdasdasd1231231da1231231}
借用一张别的大神画的图，可以更直观的看出来cookie和session的关系
知道了原理，我们下面就来用代码实现
先在templates目录下创建两个html，login.html负责登录页面。backend页面代表后台页面
login.html
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>login</title> <link rel="stylesheet" href="http://830909.blog.51cto.com/static/plugins/bootstrap-3.3.5-dist/css/bootstrap.min.css"> </head> <body> <div class="container"> <form action="login.html" method="post"> <div class="form-group"> <label class="sr-only">username</label> <input type="text" class="form-control" name="username" placeholder="用户名"/> </div> <div class="form-group"> <label class="sr-only">Password</label> <input type="password" class="form-control" name="passwd" placeholder="密码"/> </div> <div class="form-group"> <input class="btn btn-primary" type="submit" value="http://830909.blog.51cto.com/8311014/Submit"> </div> </form> </div> <script type="application/Javascript" src="http://830909.blog.51cto.com/static/js/jquery-2.2.1.min.js"></script> <script type="application/javascript" src="http://830909.blog.51cto.com/static/plugins/bootstrap-3.3.5-dist/js/bootstrap.min.js"></script> </body> </html>
backend.html
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>backend</title> <link rel="stylesheet" href="http://830909.blog.51cto.com/static/plugins/bootstrap-3.3.5-dist/css/bootstrap.min.css"> <link rel="stylesheet" href="http://830909.blog.51cto.com/static/css/commons.css"> </head> <body> <div class="container"> <h2>cookie 内容是 {{ cookie_content }}</h2> <h2>session 内容是 {{ session_content }}</h2> <h2>登录用户名 ：{{ username }}</h2> <a href="http://830909.blog.51cto.com/logout/">注销</a> </div> <script type="application/javascript" src="http://830909.blog.51cto.com/static/js/jquery-2.2.1.min.js"></script> <script type="application/javascript" src="http://830909.blog.51cto.com/static/plugins/bootstrap-3.3.5-dist/js/bootstrap.min.js"></script> </body> </html>
第二步 编辑app01应用下的views.py文件，编写代码逻辑部分
views.py
# /usr/bin/env python # coding:utf-8 from django.shortcuts import render from django.shortcuts import redirect def login(request): if request.method=="POST": username=request.POST['username'] pwd=request.POST['passwd'] if username=='abc' and pwd=='123': #设置session内部的字典内容 request.session['is_login']='true' request.session['username']='abc' #登录成功就将url重定向到后台的url return redirect('/backend/') #登录不成功或第一访问就停留在登录页面 return render(request,'login.html') def backend(request): """ 这里必须用读取字典的get()方法把is_login的value缺省设置为False， 当用户访问backend这个url先尝试获取这个浏览器对应的session中的 is_login的值。如果对方登录成功的话，在login里就已经把is_login 的值修改为了True,反之这个值就是False的 """ is_login=request.session.get('is_login',False) #如果为真，就说明用户是正常登陆的 if is_login: #获取字典的内容并传入页面文件 cookie_content=request.COOKIES session_content=request.session username=request.session['username'] return render(request,'backend.html', { 'cookie_content':cookie_content, 'session_content':session_content, 'username':username }) else: """ 如果访问的时候没有携带正确的session， 就直接被重定向url回login页面 """ return redirect('/login/') def logout(request): """ 直接通过request.session['is_login']回去返回的时候， 如果is_login对应的value值不存在会导致程序异常。所以 需要做异常处理 """ try: #删除is_login对应的value值 del request.session['is_login'] except KeyError: pass #点击注销之后，直接重定向回登录页面 return redirect('/login/')
第三步，编辑mydjango目录下的urls.py文件。设置函数与页面的绑定关系
urls.py
from django.conf.urls import url from django.contrib import admin from app01 import views urlpatterns = [ url(r'^admin/', admin.site.urls), url(r'^login/', views.login), url(r'^backend/', views.backend), url(r'^logout/', views.logout), ]
最后打开浏览器直接访问/backend/页面的时候直接就被重定向到了/login/
只有在输入了正确的用户名和密码之后才进入到了/backend/页面
从上图中我们看到有一下几点：
1、login页面正确登录的话，后台页面可以获取到浏览器携带的cookie的。
2、第一行的sessionid其实就是cookie值
3、session的内容是加密的，从客户端获取不到session的内容
4、服务端可以通过预设的key值取出session的内容并打印到前段
从火狐浏览器里查看cookie
django的session默认是存储在数据库里的，我们再到数据库查看一下真正session内容
从上图中我们看到有一下几点：
1、login页面正确登录的话，后台页面可以获取到浏览器携带的cookie的。
2、第一行的sessionid其实就是cookie值
3、session的内容是加密的，从客户端获取不到session的内容
4、服务端可以通过预设的key值取出session的内容并打印到前段
从火狐浏览器里查看cookie
django的session默认是存储在数据库里的，我们再到数据库查看一下真正session内容
下面我们再来最后的总结一下cookie和session的知识点
cookie:
# 1、获取Cookie： # request.COOKIES['key'] # request.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None) # 参数： # default: 默认值 # salt: 加密盐 # max_age: 后台控制过期时间 # 2、设置Cookie： # rep = HttpResponse(...) 或 rep ＝ render(request, ...) # # rep.set_cookie(key,value,...) # rep.set_signed_cookie(key,value,salt='加密盐',...) # 参数： # key, 键 # value='', 值 # max_age=None, 超时时间 # expires=None, 超时时间(IE requires expires, so set it if hasn't been already.) # path='/', Cookie生效的路径，/ 表示根路径，特殊的：跟路径的cookie可以被任何url的页面访问 # domain=None, Cookie生效的域名 # secure=False, https传输 # httponly=False 只能http协议传输，无法被JavaScript获取（不是绝对，底层抓包可以获取到也可以被覆盖） # 由于cookie保存在客户端的电脑上，所以，JavaScript和jquery也可以操作cookie。 # <script src='/static/js/jquery.cookie.js'></script> # $.cookie("list_pager_num", 30,{ path: '/' });
session:
Django中默认支持Session，其内部提供了5种类型的Session供开发者使用：
- 数据库（默认）
- 缓存
- 文件
- 缓存+数据库
- 加密cookie
1、数据库Session
Django默认支持Session，并且默认是将Session数据存储在数据库中，即：django_session 表中。 a. 配置 settings.py SESSION_ENGINE = 'django.contrib.sessions.backends.db' # 引擎（默认） SESSION_COOKIE_NAME ＝ "sessionid" # Session的cookie保存在浏览器上时的key，即：sessionid＝随机字符串（默认） SESSION_COOKIE_PATH ＝ "/" # Session的cookie保存的路径（默认） SESSION_COOKIE_DOMAIN = None # Session的cookie保存的域名（默认） SESSION_COOKIE_SECURE = False # 是否Https传输cookie（默认） SESSION_COOKIE_HTTPONLY = True # 是否Session的cookie只支持http传输（默认） SESSION_COOKIE_AGE = 1209600 # Session的cookie失效日期（2周）（默认） SESSION_EXPIRE_AT_BROWSER_CLOSE = False # 是否关闭浏览器使得Session过期（默认） SESSION_SAVE_EVERY_REQUEST = False # 是否每次请求都保存Session，默认修改之后才保存（默认） b. 使用 def index(request): # 获取、设置、删除Session中数据 request.session['k1'] request.session.get('k1',None) request.session['k1'] = 123 request.session.setdefault('k1',123) # 存在则不设置 del request.session['k1'] # 所有 键、值、键值对 request.session.keys() request.session.values() request.session.items() request.session.iterkeys() request.session.itervalues() request.session.iteritems() # 用户session的随机字符串 request.session.session_key # 将所有Session失效日期小于当前日期的数据删除 request.session.clear_expired() # 检查 用户session的随机字符串 在数据库中是否 request.session.exists("session_key") # 删除当前用户的所有Session数据 request.session.delete("session_key") ...
2、缓存Session
a. 配置 settings.py SESSION_ENGINE = 'django.contrib.sessions.backends.cache' # 引擎 SESSION_CACHE_ALIAS = 'default' # 使用的缓存别名（默认内存缓存，也可以是memcache），此处别名依赖缓存的设置 SESSION_COOKIE_NAME ＝ "sessionid" # Session的cookie保存在浏览器上时的key，即：sessionid＝随机字符串 SESSION_COOKIE_PATH ＝ "/" # Session的cookie保存的路径 SESSION_COOKIE_DOMAIN = None # Session的cookie保存的域名 SESSION_COOKIE_SECURE = False # 是否Https传输cookie SESSION_COOKIE_HTTPONLY = True # 是否Session的cookie只支持http传输 SESSION_COOKIE_AGE = 1209600 # Session的cookie失效日期（2周） SESSION_EXPIRE_AT_BROWSER_CLOSE = False # 是否关闭浏览器使得Session过期 SESSION_SAVE_EVERY_REQUEST = False # 是否每次请求都保存Session，默认修改之后才保存 b. 使用 同上
3、文件Session
a. 配置 settings.py SESSION_ENGINE = 'django.contrib.sessions.backends.file' # 引擎 SESSION_FILE_PATH = None # 缓存文件路径，如果为None，则使用tempfile模块获取一个临时地址tempfile.gettempdir() # 如：/var/folders/d3/j9tj0gz93dg06bmwxmhh6_xm0000gn/T SESSION_COOKIE_NAME ＝ "sessionid" # Session的cookie保存在浏览器上时的key，即：sessionid＝随机字符串 SESSION_COOKIE_PATH ＝ "/" # Session的cookie保存的路径 SESSION_COOKIE_DOMAIN = None # Session的cookie保存的域名 SESSION_COOKIE_SECURE = False # 是否Https传输cookie SESSION_COOKIE_HTTPONLY = True # 是否Session的cookie只支持http传输 SESSION_COOKIE_AGE = 1209600 # Session的cookie失效日期（2周） SESSION_EXPIRE_AT_BROWSER_CLOSE = False # 是否关闭浏览器使得Session过期 SESSION_SAVE_EVERY_REQUEST = False # 是否每次请求都保存Session，默认修改之后才保存 b. 使用 同上
4、缓存+数据库Session
数据库用于做持久化，缓存用于提高效率 a. 配置 settings.py SESSION_ENGINE = 'django.contrib.sessions.backends.cached_db' # 引擎 b. 使用 同上
5、加密cookie Session
a. 配置 settings.py SESSION_ENGINE = 'django.contrib.sessions.backends.signed_cookies' # 引擎 b. 使用 同上
扩展：Session用户验证
def login(func): def wrap(request, *args, **kwargs): # 如果未登陆，跳转到指定页面 if request.path == '/test/': return redirect('http://www.baidu.com') return func(request, *args, **kwargs) return wrap
