Python的眾多力量中的一個是它的"電池導入"哲學，當你安裝了Python，它自帶了一個巨大的常用模塊"標準庫"，你不需要
下載任何其它東西就可以立即開始使用，Django打算遵循這個哲學，它包含了它自己的對常用Web開發任務有用的附加標準庫
本章就講述這些附加物

關于標準庫
Django的標準庫位于django.contrib，其中每個子包都是一個單獨部分的附屬功能，這些包沒有必要互相關聯，但是有些
django.contrib子包可能需要其它包
在django.contrib里功能類型沒有硬性需求，其中有些包包含模型(這樣就需要在你的數據庫安裝數據庫表)，其它的包含單
獨的中間件或模板標簽
django.contrib包的共有特性是:如果你刪除整個django.contrib包，你仍然可以無誤的使用Django的基本功能，當Django
開發人員往框架添加新功能時，他們使用該規則來決定新功能應該位于django.contrib還是別的地方
django.contrib包含了如下包:
1，admin--自動admin站點，參考第6章
2，auth--Django的認證框架，參考第12章
3，comments--一個注釋框架，參考第13章
4，contenttypes--一個深入內容類型的框架，其中每個安裝的Django模型是單獨的內容類型，參考下面的"內容類型"
5，csrf--防止跨站點請求偽造(Cross Site Request Forgeries)，參考下面的"CSRF預防"
6，flatpages--在數據庫管理簡單的"平坦的"HTML，參考下面的"Flatpages"
7，formtools--Django表單的高級抽象工具，參考下面的"表單工具"
8，humanize--一些Django模板過濾器，對于給數據添加"人類感觀"很有用，參考下面的"使數據人性華"
9，markup--一些Django模板過濾器，它們實現了一些常用的標記語言，參考下面的"標記過濾器"
10，redirects--一個管理重定向的框架，參考下面的"重定向"
11，sessions--Django的session框架，參考第12章
12，sitemaps--一個生成站點圖XML文件的框架，參考下面的"Sitemaps"
13，sites--一個讓你操作同一數據庫和Django安裝的多個網站的框架，參考下面的"Sites"
14，syndication--一個在RSS和Atom生成syndication種子的框架，參考下面的"Syndication種子"
本章的其它部分進入每個django.contrib包的細節

Sites
Django的"sites"系統是一個讓你操作同一數據庫和Django項目的多個網站的框架，由于這是個抽象概念，它很難理解，所以
我們以幾個例子開始

例子1：在多個站點重用數據
我們第1章解釋到，Django驅動的站點LJWorld.com和Lawrence.com被同一新聞組織操作--堪薩斯勞倫斯的Lawrence Journal-
World報紙，LJWorld.com關注新聞，而Lawrence.com關注本地娛樂，但是有時候編輯想在兩個站點發表同一文章
解決此問題的要命的方法是為每個站點使用不同的數據庫，然后讓站點生成者發表同一個故事兩次:一次在LJWorld.com一次
在Lawrence.com，但是這使站點生成者很低效，并且它在數據庫里存儲了同一故事的多份拷貝從而造成冗余
更好的解決方案非常簡單:兩個站點使用同一文章數據庫，并且文章通過多對多關系關聯到多個站點，Django的sites框架提
供了文章可以被關聯的數據庫表，同多個"sites"關聯數據是個鉤子

例子2：在一個地方存儲你的站點名/域名
LJWorld.com和Lawrence.com都有e-mail提醒功能，這讓讀者訂閱并當新聞發生時得到告示，這非常基本:讀者在一個Web表單
訂閱，然后他立即得到一個e-mail說，"感謝你的訂閱"
實現該登錄處理代碼兩次是非常低效和冗余的，所以sites在幕后使用了同樣的代碼，但是"感謝你的訂閱"這個通知需要當前
站點的name(如'LJWorld.com')和domain(如'www.ljworld.com')的值
Django的sites框架提供了一個讓你在你的Django項目里為每個站點存儲name和domain的地方，這意味著你可以用一個一般的
方式來重用這些值

使用sites框架
sites框架不像是一個框架而更像是一些慣例，它整個東西是基于兩個簡單的概念:
1，Site模型，位于djang.contrib.sites，它有domain和name域
2，settings文件里的SITE_ID設置指定了Site對象的數據庫ID
怎樣使用這兩個概念取決于你，但是Django通過簡單的慣例用一些方式自動的使用它們
按下面的步驟安裝sites app:
1，添加'django.contrib.sites'到你的INSTALLED_APPS
2，運行命令manage.py syncdb來在你的數據庫安裝django_site表
3，通過Django的admin站點或者Python API來添加一個或多個Site對象，為該Django項目擁有的每個站點/域名創建Site對象
4，在你的每個settings文件中定義SITE_ID，這個值應該為該settings文件驅動的站點的Site對象的數據庫ID

你可以用sites框架做的事情
在多個站點間重用數據
為了像"例子1"中解釋的那樣在多個站點重用數據，只需在你的模型中創建一個ManyToManyField到Site，例如:

from django.db import models
from django.contrib.sites.models import Site

class Article(models.Model):
    headline = models.CharField(maxlength=200)
    # ...
    sites = models.ManyToManyField(Site)

這是為了在你的數據庫中將文章關聯到多個站點所需的必要基本組織，而且你還可以對多個站點重用同樣的Django視圖代碼
繼續Article例子，這里是article_detail的視圖的樣子:

from django.conf import settings

def article_detail(request, article_id):
    try:
        a = Article.objects.get(id=article_id, sites__id=settings.SITE_ID)
    except Article.DoesNotExist:
        raise Http404
    # ...

該視圖方法是可重用的，因為它根據SITE_ID設置的值來動態檢查文章的站點
例如，LJWorld.com的settings文件的SITE_ID設置為1而Lawrence.com的settings文件的SITE_ID設置為2，如果當LJWorld.
com的settings文件是活動時調用該視圖，則它將限制文章查詢在包含LJWorld.com的sites列表的文章

與單獨的站點關聯內容
同樣的，你可以使用ForeignKey和多對一關系來關聯模型到Site模型
例如，如果文章只允許在一個單獨的站點，你可以像這樣使用模型:

from django.db import models
from django.contrib.sites.models import Site

class Article(models.Model):
    headline = models.CharField(maxlength=200)
    # ...
    site = models.ForeignKey(Site)

上一部分描述了同樣的好處

從視圖進入當前站點
在更低的級別，你可以基于視圖在哪個site調用在你的Django視圖使用sites框架來做特殊的事情，例如:

from django.conf import settings

def my_view(request):
    if settings.SITE_ID == 3:
        # Do something.
    else:
        # Do something else.

當然，這丑陋的硬編碼了站點IDs，你最好趕緊修正它，一個達到同樣目的的稍微干凈的方式是檢查當前站點的域名:

from django.conf import settings
from django.contrib.sites.models import Site

def my_view(request):
    current_site = Site.objects.get(id=settings.SITE_ID)
    if current_site.domain == 'foo.com':
        # Do something
    else:
        # Do something else.

根據settings.SITE_ID得到Site對象的慣例非常常見，所以Site模型的manager(Site.objects)有一個get_current()方法
這個例子等同于前面的:

from django.contrib.sites.models import Site

def my_view(request):
    current_site = Site.objects.get_current()
    if current_site.domain == 'foo.com':
        # Do something
    else:
        # Do something else.

注意在這個最好的例子中，你不需要import djang.conf.settings

得到當前域名來顯示
對于在"例子2"中解釋的DRY(Don't Repeat Yourself)方式的存儲你的站點名和域名，只需在當前Site對象引用name和domain
例如:

from django.contrib.sites.models import Site
from django.core.mail import send_mail

def register_for_newsletter(request):
    # Check form values, etc., and subscribe the user.
    # ...
    current_site = Site.objects.get_current()
    send_mail('Thanks for subscribing to %s alerts' % current_site.name,
        'Thanks for your subscription. We appreciate it.\n\n-The %s team.' % current_site.name,
        'editor@%s' % current_site.domain,
        [user_email])
    # ...

繼續我們的LJWorld.com和Lawrence.com的例子:在Lawrence.com，這個e-mail有一個主題行"Thanks for subscribing to La
wrence.com alers."在LJWorld.com，這個e-mail主題為"Thanks for subscribing to LJWorld.com alerts."同樣的站點特
有的行為在e-mail的信息主體里完成
注意一個更靈活(但是更重量級)的完成這個的方式是使用Django的模板系統，假設Lawrence.com和LJWorld.com有不同的模板
目錄(TEMPLATE_DIRS)，你可以像這樣簡單的委派給模板系統:

from django.core.mail import send_mail
from django.template import loader, Context

def register_for_newsletter(request):
    # Check form values, etc., and subscribe the user.
    # ...
    subject = loader.get_template('alerts/subject.txt').render(Context({}))
    message = loader.get_template('alerts/message.txt').render(Context({}))
    send_mail(subject, message, 'do-not-reply@example.com', [user_email])
    # ...

這種情況下，你不需要在LJWorld.com和Lawrence.com模板目錄都創建subject.txt和message.txt模板，這給你更多的靈活性
但是也更復雜
盡可能多的使用Site對象來刪除不必要的復雜性和冗余是個好主意

為完整URLs得到當前域名
Django的get_absolute_url()慣例對不要域名而得到你的對象的URL很好，但是某些情況下你可能想顯示完整的URL--用http:
//和域名和任何東西--對于一個對象，為了做這個，你可以使用sites框架，一個簡單的例子:

>>> from django.contrib.sites.models import Site
>>> obj = MyModel.objects.get(id=3)
>>> obj.get_absolute_url()
'/mymodel/objects/3/'
>>> Site.objects.get_current().domain
'example.com'
>>> 'http://%s%s' % (Site.objects.get_current().domain, obj.get_absolute_url())
'http://example.com/mymodel/objects/3/'

CurrentSiteManager
如果Sites在你的程序里擔任一個關鍵的角色，考慮在你的模型里使用有用的CurrentSiteManager，是模型manager(參考第5
章)自動過濾它的查詢來包含當前Site相關的對象
通過顯示的添加CurrentSiteManager到你的模型中來使用它，例如:

from django.db import models
from django.contrib.sites.models import Site
from django.contrib.sites.managers import CurrentSiteManager

class Photo(models.Model):
    photo = models.FileField(upload_to='/home/photos')
    photographer_name = models.CharField(maxlength=100)
    pub_date = models.DateField()
    site = models.ForeignKey(Site)
    objects = models.Manager()
    on_site = CurrentSiteManager()

對這個模型，Photo.objects.all()將返回數據庫中所有的Photo對象，但是Photo.on_site.all()將根據SITE_ID設置只返回
當前站點相關聯的Photo對象
換句話說，這兩個語句是相等的:

Photo.objects.filter(site=settings.SITE_ID)
Photo.on_site.all()

CurrentSiteManager怎么知道Photo的哪個域是Site?它默認查找叫site的域，如果你的模型有一個ForeignKey或者ManyToMan
yField叫site以外的東西，你需要將它作為參數顯示的傳遞給CurrentSiteManager，下面的域叫publish_on的模型做了示范:

from django.db import models
from django.contrib.sites.models import Site
from django.contrib.sites.managers import CurrentSiteManager

class Photo(models.Model):
    photo = models.FileField(upload_to='/home/photos')
    photographer_name = models.CharField(maxlength=100)
    pub_date = models.DateField()
    publish_on = models.ForeignKey(Site)
    objects = models.Manager()
    on_site = CurrentSiteManager('publish_on')

如果你嘗試使用CurrentSiteManager并傳遞一個不存在的域的名字Django將觸發ValueError
最后，注意即使你使用CurrentSiteManager，你可能想在你的模型保持一個普通(非站點專有)的Manager，在第5章解釋了，
如果你手動定義一個manager，則Django不會為你自動創建objects = models.Manager()，同時注意Django的某些部分--即
Django的admin站點和generic views--使用模型中首先定義的manager，所以如果你想讓你的admin站點訪問所有的對象(而
不只是站點專有的對象)，在定義CurrentSiteManager之前把objects = models.Manager()放置到你的模型中

Django怎樣使用sites框架
盡管使用sites框架不是必需的，但這是強力推薦的，因為Django在一些地方使用它，即使你的Django安裝只是單站點驅動
你應該花費兩秒鐘來使用你的domain和name來創建site對象，并在你的SITE_ID設置里指出它的ID
這里是Django怎樣使用sites框架:
1，在重定向框架(參考下面的"重定向")中，每個重定向對象與特殊的站點相關聯，當Django搜索一個重定向時，它考慮當
前的SITE_ID
2，在注釋框架(參考第13章)中，每個注釋與特殊的站點相關聯，當發表一個注釋時，它的site設置為SITE_ID，當注釋通過
合適的模板標簽列出時，只顯示當前站點的注釋
3，在flatpages框架中(參考下面的"Flatpages")，每個flatpage與一個特殊的站點相關聯，當flatpage創建時，你指定它的
site，并且flatpage中間件在得到flatpages時檢查當前SITE_ID來顯示
4，在syndication框架中(參考下面的"Syndication種子")，title和description的模板自動訪問{{{ site }}}變量，它是
表示當前站點的Site對象，而且如果你不指定完整的域名，提供條目URLs的鉤子將使用當前Site對象的domain

Flatpages
你經常有一個數據庫驅動的Web程序要運行，但是你將需要添加一些"一次性的"靜態頁面，例如"About"頁面或者"私有政策"
頁面，可以使用標準Web服務器如Apache來將其作為平坦的HTML文件服務，但是這在你的程序中導致了額外級別的復雜度，因
為你需要擔心配置Apache，你需要建立讓你的團隊編輯這些文件的訪問方式，并且你不能使用Django的模板系統來給這些頁
面添加風格
這個問題的解決方案是Django的"flatpages"app，它位于django.contrib.flatpages包，這個app讓你通過Django的admin站
點管理這些"一次性"頁面，并讓你使用Django的模板系統為它們指定模板，它在幕后使用Django模型，這意味著你在數據庫
存儲這些頁面，就像你的其它數據一樣，并且你可以使用Django的標準數據庫API訪問flatpages
Flatpages通過它們的URL和site作為鍵來維護，當你創建一個flatpage，你指定它關聯的URL以及它所在的站點(參考上面的
"Sites"部分得到更多關于sites)

使用Flatpages
按下面步驟安裝flatpages app:
1，把'django.contrib.flatpages'添加到你的INSTALLED_APPS
2，把'django.contrib.flatpages.middleware.FlatpageFallbckMiddleware'添加到你的MIDDLEWARE_CLASSES設置
3，運行命令manage.py syncdb來安裝兩個必需的表到你的數據庫

它怎樣工作
flatpages app在你的數據庫創建了兩個表:django_flatpage和django_flatpage_sites，django_flatpage是一個簡單映射
一個URL到一個title和一些文本內容的查詢表，django_flatpage_sites是將一個flatpage同一個或多個站點關聯的多對多表
該app帶有一個單獨的FlatPage模型，定義在django/contrib/flatpages/models.py，它看起來像這樣:

from django.db import models
from django.contrib.sites.models import Site

class FlatPage(models.Model):
    url = models.CharField(maxlength=100)
    title = models.CharField(maxlength=200)
    content = models.TextField()
    enable_comments = models.BooleanField()
    template_name = models.CharField(maxlength=70, blank=True)
    registration_required = models.BooleanField()
    sites = models.ManyToManyField(Site)

讓我們一次看看所有這些域:
1，url--flatpage位于的URL，不包含域名但包含前置斜線，例如:'/about/contact/'
2，title--flatpage的title，框架不對它做任何特殊的事情，在模板中顯示它是你的責任
3，content--flatpage的內容，即頁面的HTML，框架不對它做任何特殊的事情，在模板中顯示它是你的責任
4，enable_comments--是否在flatpage允許注釋，框架不對它做任何特殊的事情，你可以在你的模板中檢查該值并需要的話
顯示一個注釋表單
5，template_name--用來渲染該flatpage的的模板名，它是可選的，如果它沒有給出，框架將使用模板flatpages/default.
html
6，registration_required--注冊對于查看該flatpage是否必需，它與第12章解釋的Django的認證/用戶框架集成
7，sites--該flatpage位于的站點，它與上面的"Sites"部分解釋的Django的sites框架繼承
你可以通過Django的admin界面或者Django數據庫API創建flatpages，參考下面的"怎樣添加，更改和刪除flatpages"
一旦你創建了flatpages，FlatpageFallbackMiddleware做所有的工作，每次Django程序觸發404錯誤時，該中間件對請求的
URL檢查flatpages數據庫作為最后的手段，特別的，它使用給定的URL和表示SITE_ID設置的站點ID來檢查flatpage
如果它找到一個匹配，它就載入flatpage的模板或者如果flatpage沒有指定自定義模板時使用flatpages/default.html，它
傳遞給模板一個單獨的context變量flatpage，它是flatpage對象，然后使用RequestContext渲染模板
如果它沒找到匹配，請求繼續照常處理
注意該中間件只為404激活--而不為500或其它狀態碼的應答，同時注意MIDDLEWARE_CLASSES的順序有關系，一般來說，你可
以將FlatpageFallbackMiddleware放在列表的末尾，因為它是最后的手段

怎樣添加，更改和刪除flatpages
通過admin界面
如果你激活了自動的Django的admin界面，你應該在admin首頁看到一個"Flatpages"部分，在系統中像編輯其它對象一樣編輯
flatpages
通過Python API
上面描述了，flatpages通過位于django/contrib/flatpages/models.py的標準Django模型來表示，這樣，你可以通過標準
Django數據庫API訪問flatpage對象，例如:

>>> from django.contrib.flatpages.models import FlatPage
>>> from django.contrib.sites.models import Site
>>> fp = FlatPage(
...     url='/about/',
...     title="About",
...     content='<p>About this site...</p>',
...     enable_comments=False,
...     template_name='',
...     registration_required=False,
... )
>>> fp.save()
>>> fp.sites.add(Site.objects.get(id=1))
>>> FlatPage.objects.get(url='/about/')
<FlatPage: /about/ -- About>

Flatpage模板
flatpages默認通過模板flatpages/default.html渲染，但是你可以對應該特殊的flatpage覆蓋它
創建flatpages/default.html模板是你的責任，在你的模板目錄創建flatpages目錄并包含一個default.html文件
Faltpage模板傳遞了一個單獨的context變量flatpage，它是flatpage對象
這里是flatpages/default.html模板的例子:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
    "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
<title>{{ flatpage.title }}</title>
</head>
<body>
{{ flatpage.content }}
</body>
</html>

重定向
Django的重定向框架讓你通過在數據庫里存儲它們來輕松管理重定向并把它們當作其它Django模型對象，例如你可以使用重
定向框架來告訴Django，"重定向任何對/music/的請求到/sections/arts/music/"

使用重定向框架
按下面步驟安裝重定向app:
1，把'django.contrib.redirects'安裝到你的INSTALLED_APPS
2，把'django.contrib.redirects.middleware.RedirectFallbackMiddleware'添加到你點MIDDLEWARE_CLASSES設置
3，運行命令manage.py syncdb來安裝單獨的必需表到你的數據庫

它怎樣工作
manage.py syncdb在你的數據庫安裝了一個django_redirect表，它是有site_id，old_path和new_path域的簡單查詢表
你可以通過Django的admin界面或者Django數據庫API創建重定向，參考下面的"怎樣添加，更改和刪除重定向"
一旦你創建了重定向，RedirectFallbackMiddleware做所有的工作，每次Django程序觸發了404錯誤，中間件都將檢查重定向
表作為最后的手段，特別的，它使用給定的old_path和表示SITE_ID設置的站點ID來檢查重定向(參考上面的"Sites"來得到更
多關于SITE_ID和sites框架)，然后，它遵循下面的步驟:
1，如果它找到匹配，并且new_path不為空，則它將重定向到new_path
2，如果它找到匹配，并且new_path為空，它發送一個410("不存在")HTTP頭部和空(無內容)應答
3，如果它找不到匹配，請求繼續照常處理
中間件只為404激活--不為400或者任何其它狀態碼的應答
注意MIDDLEWARE_CLASSES的順序有關系，一般來說，你可以將RedirectFallbackMiddleware放置在列表末尾，因為它是最后
的手段

怎樣添加，更改和刪除重定向
通過admin界面
如果你激活了自動的Django的admin界面，你應該在admin首頁看到一個"重定向"部分，在系統中像編輯任何其它對象一樣編
輯重定向
通過Python API
重定向通過位于django/contrib/redirects/models.py的標準Django模型表示，這樣你可以通過Django數據庫API訪問重定向
對象，例如:

>>> from django.contrib.redirects.models import Redirect
>>> from django.contrib.sites.models import Site
>>> red = Redirect(
...     site=Site.objects.get(id=1),
...     old_path='/music/',
...     new_path='/sections/arts/music/',
... )
>>> red.save()
>>> Redirect.objects.get(old_path='/music/')
<Redirect: /music/ ---> /sections/arts/music/>

CSRF防護
django.contrib.csrf包提供了容易使用的跨站點請求偽造Cross-Site Request Forgeries(CSRF)防護

CSRF解釋
CSRF，也稱為"session駕馭"，它是一個Web站點安全開拓，當一個惡毒的網站欺騙用戶未知的從一個他們已經認證站點載入
一個URL--這樣就可以使用他們的認證狀態，這起初可能有點難以理解，所以這里我們包含了兩個例子:
一個簡單的例子
比如說你已經在example.com登錄了一個webmail帳號，這個webmail站點有一個"注銷"按鈕指向URL為example.com/logout--
即你為了注銷所需要做的唯一的動作是訪問example.com/logout頁面
惡毒的站點可以通過把URL example.com/logout包含在他自己(惡毒的)頁面的一個隱藏的iframe來強迫你訪問該URL，這樣
如果你在example.com登錄了webmail帳號并訪問有example.com/logout的iframe的惡毒頁面，訪問該惡毒頁面的結果是將
你從example.com注銷
顯然，不按你的意愿從一個webmail站點注銷不是令人恐怖的安全漏洞，但是同類型的開拓可以發生在任何"信任"用戶的站點
--例如銀行站點或電子商務站點
一個更復雜的例子
在上個例子中，example.com部分有故障，因為他允許通過HTTP GET方法做狀態更改(即注銷你自己)，對任何請求需要HTTP
POST來在服務器更改狀態是一個良好實踐，但是即使Web站點需要POST來做狀態改變對于CSRF也很易受到攻擊
比方說example.com升級了它的"注銷"功能為一個form按鈕來通過POST到URL example.com/logout來請求，而且，注銷form
包含下面隱藏域:

<input type="hidden" name="confirm" value="true" />

這保證了簡單的POST到URL example.com/logout將不執行注銷，為了讓用戶注銷，用戶必須通過POST并發送confirm POST變
量且值為'true'
但是不管額外的安全，這種方式仍然可以被CSRF開拓，惡毒的頁面只需做一點更多的工作，取代在iframe載入example.com/
logout頁面，它可以通過使用JavaScript和POST來調用該URL，并傳遞confirm=true變量
防止
這樣的話，怎樣防止你的站點被開拓呢?
第一步是確認所有的GET請求沒有副作用，這樣，如果惡毒的站點包含了一個你的頁面作為iframe，它將沒有壞作用
第二步是給每個POST表單一個隱藏域，值為隱秘的并從用戶的session ID生成，這樣，當在服務器端處理時檢查隱秘域，如
果它不合法則觸發一個異常
這就是Django的CSRF預防層做的事情

使用CSRF中間件
djang.csrf包只包含一個模塊:middleware.py，該模塊包含了Django的中間件類CsrfMiddleware，它實現了CSRF預防
為了使用它，把'django.contrib.csrf.middleware.CsrfMiddleware'添加到你的settings文件的MIDDLEWARE_CLASSes設置中
這個中間件需要在SessionMiddleware之后處理應答，所以CsrfMiddleware必須放在列表的SessionMiddleware之前，它也必
須在應答被壓縮或切碎之前處理，所以CsrfMiddleware必須放在GZipMiddleware之后
一旦你將它添加到你的MIDDLEWARE_CLASSES設置中，你就完成了，這是你需要做的所有的事情

它怎樣工作
如果你感興趣，這里是關于CsrfMiddleware怎樣工作，它做這兩件事情:
1，它通過使用csrfmiddlewaretoken名和session ID加上密碼的hash值來添加一個隱藏域到所有的POST表單來修改外出的請
求，如果沒有session ID設置則中間件不修改應答，所以執行處罰對于不使用sessions的請求可以忽略
2，對于所有進來的有session cookie設置的POST請求，它檢查csrfmiddlewaretoken存在并正確，如果不是這樣，用戶將得
到一個403HTTP錯誤，403錯誤頁面的內容是"發現跨站點請求偽造，請求中止"的信息
這確保了只有你的網站的原始表單可以用來POST回數據
該中間件故意只針對HTTP POST請求(以及相應的POST表單)，我們上面解釋了，GET請求應該從來沒有副作用，確保這點是你
自己的責任
不通過session cookie完成的POST請求不被預防，但是它們也不需要預防，因為惡毒的網站不會偽造這種類型的請求
為了防止更改非文本請求，中間件在修改它之前檢查應答的Content-Type頭部，只有格式為text/html或者application/xml
+xhtml的頁面被修改

限制
CsrfMiddleware需要Django的session框架來工作(參考第12章)，如果你正在使用一個自定義的手動慣例session cookie的
session或者認證框架，該中間件將不能幫助你
如果你的app用一些不尋常的方式創建HTML頁面和表單--例如，如果它用JavaScript的document.write語句傳遞HTML碎片--你
可能迂回添加隱藏域到表單的過濾器，這種情況下，表單提交將一直出錯(這會發生因為CsrfMiddleware使用正則表達式來在
頁面發送到客戶端之前添加csrfmiddlewaretoken域到你的HTML，而正則表達式有時候不能處理古怪的HTML)，如果你懷疑這
可能發生，只需在你的瀏覽器查看源代碼來看看csrfmiddlewaretoken是否插入到你的表單
訪問http://en.wikipedia.org/wiki/Csrf來得到更多關于CSRF的信息和例子

內容類型
This section hasn't been written yet.

表單工具
This section hasn't been written yet.

使數據人性化
This section hasn't been written yet.

標記過濾器
This section hasn't been written yet.

Syndication種子
This section hasn't been written yet.
安徽新華電腦學校專業職業規劃師為你提供更多幫助【在線咨詢】