Django-url反向解析与csrf-token设置
url反向解析
在使用Django 项目时，一个常见的需求是获得URL 的最终形式，以用于嵌入到生成的内容中（视图中和显示给用户的URL等）或者用于处理服务器端的导航（重定向等）。
人们强烈希望不要硬编码这些URL（费力、不可扩展且容易产生错误）或者设计一种与URLconf 毫不相关的专门的URL 生成机制，因为这样容易导致一定程度上产生过期的URL。
换句话讲，需要的是一个DRY 机制。除了其它优点，它还允许设计的URL 可以自动更新而不用遍历项目的源代码来搜索并替换过期的URL。
要获取一个URL，最初拥有的信息是负责处理它的视图的标识（例如名字），与查找正确的URL 的其它必要的信息如视图参数的类型（位置参数、关键字参数）和值。
Django 提供了一个解决方案使得URL 映射是URL 设计唯一的储存库。你用你的URLconf填充它，然后可以双向使用它：
- 根据用户/浏览器发起的URL 请求，它调用正确的Django 视图，并从URL 中提取它的参数需要的值。
- 根据Django 视图的标识和将要传递给它的参数的值，获取与之关联的URL。
第一种方式是我们在前面的章节中一直讨论的用法。第二种方式叫做反向解析URL、反向URL匹配、反向URL查询或者简单的URL反查。
在需要URL 的地方，对于不同层级，Django 提供不同的工具用于URL 反查：
- 在模板中：使用url模板标签。
- 在Python 代码中：使用django.core.urlresolvers.reverse() 函数。
- 在更高层的与处理Django 模型实例相关的代码中：使用get_absolute_url() 方法。
例子
考虑一下URLconf:
from django.conf.urls import url from . import views urlpatterns = [ #... url(r'^articles/([0-9]{4})/$', views.year_archive, name='news-year-archive'), #... ]
根据这里的设计，某一年nnnn对应的归档的URL是/articles/nnnn/。
你可以在模板的代码中使用下面的方法获得它们：
<a href="{% url 'news-year-archive' 2012 %}">2012 Archive</a> <ul> {% for yearvar in year_list %} <li><a href="{% url 'news-year-archive' yearvar %}">{{ yearvar }} Archive</a></li> {% endfor %} </ul>
注意：上面的传参方式！！
在python代码，可以这样使用：
from django.core.urlresolvers import reverse from django.http import HttpResponseRedirect def redirect_to_year(request): # ... year = 2006 # ... return HttpResponseRedirect(reverse('news-year-archive', args=(year,)))# 注意传参方式
在某些场景中，一个视图是通用的，所以在URL 和视图之间存在多对一的关系。对于这些情况，当反查URL 时，只有视图的名字还不够。
URL模式的命名
当命名你的URL 模式时，请确保使用的名称不会与其它应用中名称冲突。如果你的URL 模式叫做comment，而另外一个应用中也有一个同样的名称，当你在模板中使用这个名称的时候不能保证将插入哪个URL。
在URL 名称中加上一个前缀，比如应用的名称，将减少冲突的可能。我们建议使用myapp-comment 而不是comment。
反查带命名空间的URL
当解析一个带命名空间的URL（例如'polls:index'）时，Django 将切分名称为多个部分，然后按下面的步骤查找：
-
首先，Django 查找匹配的应用命名空间(在这个例子中为'polls'）。这将得到该应用实例的一个列表。
-
如果有一个当前应用被定义，Django 将查找并返回那个实例的URL 解析器。当前应用可以通过请求上的一个属性指定。预期会具有多个部署的应用应该设置正在处理的request 的current_app 属性。
-
如果没有当前应用。Django 将查找一个默认的应用实例。默认的应用实例是实例命名空间 与应用命名空间 一致的那个实例（在这个例子中，polls 的一个叫做'polls' 的实例）。
-
如果没有默认的应用实例，Django 将挑选该应用最后部署的实例，不管实例的名称是什么。
-
如果提供的命名空间与第1步中的应用命名空间 不匹配，Django 将尝试直接将此命名空间作为一个实例命名空间查找。
-
如果有嵌套的命名空间，将为命名空间的每个部分重复调用这些步骤直至剩下视图的名称还未解析。然后该视图的名称将被解析到找到的这个命名空间中的一个URL。
例子：
为了演示解析的策略，考虑教程中polls 应用的两个实例：'author-polls' 和'publisher-polls'
urls.py from django.conf.urls import include, url urlpatterns = [ url(r'^author-polls/', include('polls.urls', namespace='author-polls', app_name='polls')), url(r'^publisher-polls/', include('polls.urls', namespace='publisher-polls', app_name='polls')), ]
polls/urls.py from django.conf.urls import url from . import views urlpatterns = [ url(r'^$', views.IndexView.as_view(), name='index'), url(r'^(?P<pk>\d+)/$', views.DetailView.as_view(), name='detail'), ... ]
在模板中使用：
{% url 'polls:index' %}
跨站请求伪造保护
使用规则
-
CSRF 中间件在MIDDLEWARE_CLASSES 设置中默认启用。如果你要覆盖这个设置，请记住 'django.middleware.csrf.CsrfViewMiddleware' 应该位于其它任何假设CSRF 已经处理过的视图中间件之前。
如果你关闭了它，虽然不建议，你可以在你想要保护的视图上使用csrf_protect()。
-
在使用POST 表单的模板中，对于内部的URL请在<form> 元素中使用csrf_token 标签：
<form action="." method="post">
它不应该用于目标是外部URL 的POST 表单，因为这将引起CSRF 信息泄露而导致出现漏洞。
-
在对应的视图函数中，确保使用 'django.template.context_processors.csrf' Context 处理器。通常可以用两种方法实现：
-
使用RequestContext，它会始终使用'django.template.context_processors.csrf'（无论 TEMPLATES 设置中配置的是什么模板上下文处理器）。如果你正在使用通用视图或Contrib 中的应用，你就不用担心了，因为这些应用通篇都使用RequestContext。
AJAX
虽然上面的方法可以用于AJAX POST 请求，但是它不太方便：你必须记住在每个POST 请求的数据中传递CSRF token。由于这个原因，还有另外一种方法：在每个XMLHttpRequest 上设置一个自定义的X-CSRFToken 头部，其值为CSRF token。这非常容易，因为许多JavaScript 框架都提供在每个请求上设置头部的方法。
第一步，你必须获得CSRF token。建议从csrftoken Cookie 中获取，如果你在视图中启用CSRF 防护它就会设置。
注：
CSRF token 的Cookie 默认叫做csrftoken，你可以通过CSRF_COOKIE_NAME 设置自定义它的名字。
获取token 非常简单：
// using jQuery function getCookie(name) { var cookieValue = null; if (document.cookie && document.cookie != '') { var cookies = document.cookie.split(';'); for (var i = 0; i < cookies.length; i++) { var cookie = jQuery.trim(cookies[i]); // Does this cookie string begin with the name we want? if (cookie.substring(0, name.length + 1) == (name + '=')) { cookieValue = decodeURIComponent(cookie.substring(name.length + 1)); break; } } } return cookieValue; } var csrftoken = getCookie('csrftoken');
以上代码可以使用jquery.cookie.js来替换getCookie：
var csrftoken = $.cookie('csrftoken');
function csrfSafeMethod(method) { return (/^(GET|HEAD|OPTIONS|TRACE)$/.test(method)); } $.ajaxSetup({//全局设置csrf-token beforeSend:function (xhr,settings) { //请求头设置一次csrf-token if (!csrfSafeMethod(settings.type)){ xhr.setRequestHeader('X-CSRFToken',$.cookie('csrftoken'));//在每次请求的cookie中设置csrftoken } } });
注：CSRF token 也存在于DOM 中，但只有你在模板中明确使用csrf_token 标签时才有。如果你的视图渲染的模板没有包含csrf_token 标签，Django 可能不会再Cookie 中设置CSRF token。这常见于表单是动态的方式添加到网页中的。为了解决这个问题，Django 提供一个视图装饰器ensure_csrf_cookie()，它将强制设置这个Cookie。
from django.views.decorators.csrf import ensure_csrf_cookie
将此装饰器强制设置在视图上。
场景
CSRF保护应该禁用只有几个视图
大多数视图需要CSRF保护，但有几个不需要。
解决方案：而不是禁用中间件，并对所有需要它的视图应用csrf_protect，启用中间件并使用csrf_exempt()。
from django.views.decorators.csrf import csrf_exempt from django.http import HttpResponse @csrf_exempt def my_view(request): return HttpResponse('Hello world')
CsrfViewMiddleware.process_view未使用
有些情况下，如果CsrfViewMiddleware.process_view可能在您的视图运行之前没有运行 - 例如404和500处理程序，但是您仍然需要一个表单中的CSRF令牌。
解决方案：使用requires_csrf_token()
from django.views.decorators.csrf import requires_csrf_token from django.shortcuts import render @requires_csrf_token def my_view(request): c = {} # ... return render(request, "a_template.html", c)
不受保护的视图需要CSRF令牌
可能有一些视图未受保护，并且已被csrf_exempt豁免，但仍需要包括CSRF令牌。
解决方案：使用csrf_exempt()，后跟requires_csrf_token()。（即requires_csrf_token应该是最内部的装饰器）。
View需要保护一个路径
视图仅需要一组条件下的CSRF保护，并且在其余时间内不能拥有它。
解决方案：对于需要保护的路径，使用csrf_exempt()作为整个视图函数，csrf_protect()例：
from django.views.decorators.csrf import csrf_exempt, csrf_protect @csrf_exempt def my_view(request): @csrf_protect def protected_path(request): do_something() if some_condition(): return protected_path(request) else: do_something_else()
页面使用AJAX，没有任何HTML表单
网页通过ajax发出post请求，并且该网页没有带有csrf_token的HTML表单，就会导致所需的CSRF Cookie被发送。
解决方案：在发送页面的视图上使用ensure_csrf_cookie()。
