Django 2.1.3 文件 開發程序 完整設定列表
設定
- 1. 核心設定
- ADMINS
- ALLOWED_HOSTS
- APPEND_SLASH
- 1.1 快取
- 1.2 安全
- CSRF_COOKIE_AGE
- CSRF_COOKIE_DOMAIN
- CSRF_COOKIE_HTTPONLY
- CSRF_COOKIE_NAME
- CSRF_COOKIE_PATH
- CSRF_COOKIE_SAMESITE
- CSRF_COOKIE_SECURE
- CSRF_USE_SESSIONS
- CSRF_FAILURE_VIEW
- CSRF_HEADER_NAME
- CSRF_TRUSTED_ORIGINS
- 1.3 資料庫
- DATABASE
- ATOMIC_REQUESTS
- AUTOCOMMIT
- ENGINE
- HOST
- NAME
- CONN_MAX_AGE
- OPTIONS
- PASSWORD
- PORT
- TIME_ZONE
- DISABLE_SERVER_SIDE_CURSORS
- USER
- TEST
- CHARSET
- COLLATION
- DEPENDENCIES
- MIRROR
- NAME
- SERIALIZE
- TEMPLATE
- CREATE_DB
- CREATE_USER
- USER
- PASSWORD
- TBLSPACE
- TBLSPACE_TMP
- DATAFILE
- DATAFILE_TMP
- DATAFILE_MAXSIZE
- DATAFILE_TMP_MAXSIZE
- DATAFILE_SIZE
- DATAFILE_TMP_SIZE
- DATAFILE_EXTSIZE
- DATAFILE_TMP_EXTSIZE
- DATABASE_ROUTERS
- 1.4 HTTP
- 1.5 全球化(i18n/ l10n)
- DATE_FORMAT
- DATE_INPUT_FORMATS
- DATETIME_FORMAT
- DATETIME_INPUT_FORMATS
- DECIMAL_SEPARATOR
- FIRST_DAY_OF_WEEK
- FORMAT_MODULE_PATH
- INSTALLED_APPS
- TIME_ZONE
- USE_I18N
- USE_L10N
- 1.4 USE_TZ
不斷更新中,更新完畢,刪除本句。
警告
覆蓋設定時要小心,特別是當預設值是非空列表或字典時,例如STATICFILES_FINDERS。確保保留您希望使用的Django功能所需的元件。
1. 核心設定
這是Django中可用的核心設定列表及其預設值。下面列出了應用程式提供的設定,然後是核心設定的主題索引。有關介紹性資料,請參閱 設定主題指南。
ADMINS
預設值:[]
( 空列表)
獲取程式碼錯誤通知的所有人員的列表。當 DEBUG=False
而且在LOGGING中配置了AdminEmailHandler
(預設配置),Django會郵件通知這些人在請求/響應週期內發生異常的細節。
列表中的每個專案都應該是(Full name, email address)
的這種格式的二元組。例:
[('John', '[email protected]'), ('Mary', '[email protected]')]
ALLOWED_HOSTS
預設值:[]
( 空列表)
表示此Django站點可以提供服務的主機/域名的字串列表。這是一種防止HTTP主機頭攻擊的安全措施,即使在許多看似安全的Web伺服器配置下也是如此。
此列表中的值可以是完全限定名稱(例如'www.example.com'
),在這種情況下,它們將與請求的Host標頭完全匹配(不區分大小寫,不包括埠)。用了點開頭的值可以用作一個子域萬用字元:'.example.com'
將匹配 example.com
,www.example.com
以及任何其他 example.com的子域。值'*'
將匹配任何東西; 在這種情況下,您有責任提供自己的Host標頭驗證(可能在中介軟體中;如果是這樣,則必須首先在MIDDLEWARE
配置中列出此中介軟體 )。
Django還允許任何條目的 FQDN。有些瀏覽器在Host頭中包含一個尾隨點,Django在執行主機驗證時會將其刪除。
如果Host頭(或者X-Forwarded-Host (如果 USE_X_FORWARDED_HOST已啟用))與此列表中的任何值都不匹配,django.http.HttpRequest.get_host()
方法將引發 SuspiciousOperation
。
當DEBUG=True
並且ALLOWED_HOSTS
為空時,將驗證主機['localhost', '127.0.0.1', '[::1]']
。
ALLOWED_HOSTS進行測試時也會檢查。
此驗證僅適用於get_host(); 如果您的程式碼直接從request.META
您訪問Host頭,則繞過此安全保護。
APPEND_SLASH
預設:True
設定為True時,如果請求URL與URLconf中的任何模式都不匹配,並且它不以斜槓結尾,則會向相同的URL發出HTTP重定向,並附加斜槓。請注意,重定向可能導致POST請求中提交的任何資料丟失。
APPEND_SLASH僅在CommonMiddleware
安裝時(預設安裝)使用(請參閱中介軟體)。另見PREPEND_WWW
。
1.1 快取
CACHES
預設:
# The cache backends to use.
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
}
}
包含Django使用的所有快取的設定的字典。它是一個巢狀字典,其內容將快取別名對映到包含單個快取選項的字典。
必須配置default快取; 還可以指定任意數量的附加快取。如果您使用的是除本地記憶體快取之外的快取後端,或者您需要定義多個快取,則還需要其他選項。以下快取選項可用。
BACKEND
預設值:''
( 空字串)
後端要使用的快取。
內建快取後端 | 針對型別 |
---|---|
'django.core.cache.backends.db.DatabaseCache' |
資料庫 |
'django.core.cache.backends.dummy.DummyCache' |
開發除錯 |
'django.core.cache.backends.filebased.FileBasedCache' |
檔案 |
'django.core.cache.backends.locmem.LocMemCache' |
記憶體 |
'django.core.cache.backends.memcached.MemcachedCache' |
python-memcached模組 |
'django.core.cache.backends.memcached.PyLibMCCache' |
pylibmc模組 |
您可以通過設定BACKEND為快取後端類的完全限定路徑(即mypackage.backends.whatever.WhateverCache)來使用Django未附帶的快取後端。
譯者注:比如使用redis快取
KEY_FUNCTION
包含函式(或任何可呼叫函式)的虛擬路徑的字串,用於定義如何將字首,版本和金鑰組合為最終快取金鑰。預設實現等同於函式:
def make_key(key, key_prefix, version):
return ':'.join([key_prefix, str(version), key])
您可以使用任何所需的key功能,只要它具有相同的引數簽名即可。
有關更多資訊,請參閱快取文件。
KEY_PREFIX
預設值:''
( 空字串)
一個字串,將自動包含(預設情況下預先新增)到Django伺服器使用的所有快取的key中。
有關更多資訊,請參閱快取文件。
LOCATION
預設值:''
( 空字串)
要使用的快取的位置。這可能是檔案系統快取的目錄,memcache伺服器的主機和埠,或者只是本地記憶體快取的標識名稱。例如:
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
'LOCATION': '/var/tmp/django_cache',
}
}
OPTIONS
預設: None
傳遞給快取後端的額外引數。可用引數因快取後端而異。
有關可用引數的一些資訊可以在 快取引數 文件中找到。有關更多資訊,請參閱後端模組自己的文件。
TIMEOUT
預設:300
快取記憶體項被認為是過期的秒數。如果此設定的值為None
,則快取項不會過期。
VERSION
預設: 1
Django伺服器生成的快取key的預設版本號。
有關更多資訊,請參閱快取文件。
CACHE_MIDDLEWARE_ALIAS
預設: default
用於快取中介軟體的快取連線。
CACHE_MIDDLEWARE_KEY_PREFIX
預設值:''
( 空字串)
一個字串,它將作為快取中介軟體生成的快取key的字首。此字首與KEY_PREFIX
組合設定 ; 它不會取代它。
請參閱Django的快取框架。
CACHE_MIDDLEWARE_SECONDS
預設: 600
快取一個快取中介軟體頁面的預設秒數。
請參閱Django的快取框架。
1.2 安全
譯者注:
csrf 部分都需要一個form表單和一個{% csrf_token %}
,現定義如下:
<form action="{% url 'polls:index' %}" method="post">
{% csrf_token %}
使用者名稱:<input type="text" name="username"/>
<input type="submit" value="提交"/>
</form>
CSRF_COOKIE_AGE
預設值:31449600
( 大約1年,以秒為單位)
CSRF cookie的時限,以秒為單位。
設定很長的到期時間的原因是為了避免在使用者關閉瀏覽器或為頁面新增書籤然後從瀏覽器快取載入該頁面時出現問題。如果沒有永續性cookie,表單提交在這種情況下將失敗。
某些瀏覽器(特別是Internet Explorer)可能會禁止使用永續性cookie,或者可能會將磁碟上的cookie的索引損壞,從而導致CSRF保護檢查(有時間歇性地)失敗。將此設定更改None
的含義是使用基於會話的CSRF cookie,它將cookie保留在記憶體中而不是持久儲存中。
譯者例項:
a. 通過form表單提交任意資料
b. 檢視HTTP響應中的CSRF cookie,其過期時間是2019.12.04(當前是2018.12.05)。
c. 在settings.py
檔案中新增設定
CSRF_COOKIE_AGE = 60 * 60
d. 重複a 操作的結果如下,過期時間變為一小時之後
CSRF_COOKIE_DOMAIN
預設: None
設定CSRF cookie時要使用的域。這對於輕鬆允許跨子域請求從正常的跨站點請求偽造保護中排除非常有用。它應設定為一個字串,"example.com"
允許來自另一個子域的檢視接受來自一個子域上的表單的POST請求。
請注意,此設定的存在並不意味著預設情況下Django的CSRF保護不會受到跨子域攻擊 - 請參閱 CSRF限制部分。
CSRF_COOKIE_HTTPONLY
預設: False
是否在CSRF cookie上使用標誌HttpOnly
。如果設定為 True,則客戶端JavaScript將無法訪問CSRF cookie。
將CSRF cookie指定為HttpOnly不提供任何實際保護,因為CSRF僅用於防止跨域攻擊。如果攻擊者可以通過JavaScript讀取cookie,那麼就瀏覽器所知,他們已經在同一個域中,所以無論如何他們都可以做任何他們喜歡的事情。(XSS比CSRF更具威脅。)
雖然這種設定幾乎沒有什麼實際效益,但安全稽核員有時會要求它。
如果啟用此功能並需要使用AJAX請求傳送CSRF token的值,則JavaScript必須從隱藏的CSRF token表單輸入而不是從cookie中提取值。
有關詳情,請參閱SESSION_COOKIE_HTTPONLY中的 HttpOnly。
譯者例項:
a. 通過form表單提交任意資料
b. 在客戶端js中訪問cookie,程式碼和輸出如下所示
$(".button").click(function () {
console.log(document.cookie);
})
# 控制檯輸出結果
csrftoken=3yNfXGBrrGvCtfqXm5bMnH5fEslIFeaipGVIOeDDT9nk2l0E9ltPYpYHOSs39rEc1
c. 修改設定檔案,增加
CSRF_COOKIE_HTTPONLY = True
d. 重複b操作,控制檯輸出結果是空白,檢視cookie,多了一個標誌
e. 非 csrf 相關的cookie依然可以訪問到(例如,我自己新增的hello)。
CSRF_COOKIE_NAME
預設: 'csrftoken'
用於CSRF身份驗證令牌的cookie的名稱。這可以是您想要的任何內容(只要它與您應用程式中的其他cookie名稱不同)。請參閱 跨站請求偽造保護。
譯者例項:
a. 修改設定檔案,增加
CSRF_COOKIE_NAME = 'guess-me'
b. 通過form表單提交任意資料
c. 檢視cookie,名稱發生了變化。
CSRF_COOKIE_PATH
預設: '/'
CSRF cookie上設定的路徑。這應該與Django安裝的URL路徑匹配,或者是該路徑的父路徑。
如果您在同一主機名下執行多個Django例項,這將非常有用。他們可以使用不同的cookie路徑,每個例項只能看到自己的CSRF cookie。
譯者例項:
a. 在8000埠上開啟服務,通過form表單提交任意資料,檢視cookie如下:
b. 修改配置檔案,增加
CSRF_COOKIE_PATH = '/newi/'
c. 在9000埠上再開啟一個服務,通過form表單提交任意資料,檢視cookie如下:
CSRF_COOKIE_SAMESITE
Django 2.1中的新功能:
預設:'Lax'
CSRF cookie上的SameSite標誌的值。此標誌可防止cookie在跨站請求中傳送。
有關SameSite詳情,請參閱SESSION_COOKIE_SAMESITE。
CSRF_COOKIE_SECURE
預設: False
是否為CSRF cookie使用安全cookie。如果設定為True,則cookie將被標記為“安全”,這意味著瀏覽器可以確保cookie僅通過HTTPS連線傳送。
CSRF_USE_SESSIONS
預設:False
是否將CSRF token儲存在使用者的會話中而不是cookie中。它需要使用django.contrib.sessions(INSTALLED_APPS中預設安裝)。
將CSRF token儲存在cookie中(Django的預設值)是安全的,但將其儲存在會話中是其他Web框架中的常見做法,因此有時需要問一下安全審計員。
譯者例項:
a. 首先將我的django_session
表清空
c. 在settings.py
檔案中設定CSRF_USE_SESSIONS=True
d. 構建一個form表單新增{% csrf_token %}
並提交
e. 在django_session
中多出一條記錄,session_data列的內容為base64編碼之後的內容
f. 將base64內容進行解碼,得到
2330bd978b9e64884c55824f40ae39949c0beb3f:{"_csrftoken":"M99bIEOy9ICmtuO5vHHdpVRyXIoJjO0hIvR6uMiP7pINgPzu306PjuKbKfFtCJQd"}
7. 此時檢視瀏覽器的cookie,如下:
(7)在settings.py
檔案中設定CSRF_USE_SESSIONS=False
,並且重複c操作
,並且再次檢視瀏覽器的cookie,如下:
CSRF_FAILURE_VIEW
預設: 'django.views.csrf.csrf_failure'
當CSRF保護拒絕傳入請求時要使用的檢視函式的虛擬路徑。該函式應具有此中形式:
def csrf_failure(request, reason=""):
...
...
其中reason是一條短訊息(用於開發人員或日誌記錄,而不是終端使用者),指示請求被拒絕的原因。它應該返回一個HttpResponseForbidden。
django.views.csrf.csrf_failure()
接受附加引數template_name, 預設的'403_csrf.html'
。如果存在具有該名稱的模板,則它將用於呈現頁面。
譯者例項:
其實此設定的功能就是自定義csrf token丟失的提示頁面。
a. 構建一個form表單,不提供{% csrf_token %}
,提交請求之後的頁面如下所示:
b. 在設定檔案中新增
CSRF_FAILURE_VIEW = 'polls.utils.my_csrf_failure'
c. my_csrf_failure
函式的定義如下
from django.http import HttpResponseForbidden
from django.template import Context, Engine, TemplateDoesNotExist, loader
from django.utils.translation import gettext as _
CSRF_FAILURE_TEMPLATE = """
<!DOCTYPE html>
<html lang="en">
<head>
</head>
<body>
{{title}}<br>
<h1> CSRF 403 FORBIDDEN</h1>
{{reason}}<br>
</body>
</html>
"""
CSRF_FAILURE_TEMPLATE_NAME = "403_csrf.html"
def my_csrf_failure(request, reason="", template_name=CSRF_FAILURE_TEMPLATE_NAME):
"""
Default view used when request fails CSRF protection
"""
c = {
'title': _("Forbidden"),
'reason': reason,
}
try:
t = loader.get_template(template_name)
except TemplateDoesNotExist:
if template_name == CSRF_FAILURE_TEMPLATE_NAME:
# If the default template doesn't exist, use the string template.
t = Engine().from_string(CSRF_FAILURE_TEMPLATE)
c = Context(c)
else:
# Raise if a developer-specified template doesn't exist.
raise
return HttpResponseForbidden(t.render(c), content_type='text/html')
e. 重複 a 操作後,看到的頁面如下所示:
CSRF_HEADER_NAME
預設: 'HTTP_X_CSRFTOKEN'
用於CSRF身份驗證的請求頭的名稱。
與request.META中的其他HTTP頭一樣,從伺服器接收的請求頭名稱將所有字元轉換為大寫,用下劃線替換任何連字元,併為名稱新增字首'HTTP_'
·來規範化。例如,如果您的客戶端傳送'X-XSRF-TOKEN'
頭,則設定應為'HTTP_X_XSRF_TOKEN'
。
譯者例項:
a. 追溯了一下原始碼,如下所示,能看出來此標誌的作用,就是在POST表單中如果獲取不到csrfmiddlewaretoken
的值,就去CSRF_HEADER_NAME
裡面找:
# django.middleware.csrf.py
def process_view(self, request, callback, callback_args, callback_kwargs):
...
if request.method == "POST":
try:
request_csrf_token = request.POST.get('csrfmiddlewaretoken', '')
except IOError:
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)
...
b. 讓我們用form表單提交POST資料,抓包看下請求內容是什麼:
可以在請求體裡看到多了一個django自己新增的csrfmiddlewaretoken鍵值對,有了這個就不會報403錯誤了。
c. 讓我們去掉這個csrfmiddlewaretoken重新發送,結果毫無意外地403:
d.在設定檔案中新增
CSRF_HEADER_NAME = 'HTTP_X_XSRF_TOKEN'
e.讓我們用form表單提交POST資料,同時增加一個HTTP頭為
X-XSRF-TOKEN
,值同csrfmiddlewaretoken(請求體中去掉csrfmiddlewaretoken鍵值對)。
f.觀察結果,沒有403出現了,相應結果正常。
CSRF_TRUSTED_ORIGINS
預設值:[]
( 空列表)
主機列表,它是不安全請求的可信來源(例如POST)。對於一個不安全的HTTPS請求,Django的CSRF保護機制要求該請求中地Referer 頭和Host頭同源。例如,這可以防止來自subdomain.example.com
的POST能成功請求api.example.com
(譯者注:去了解下同源策略)。如果您需要通過HTTPS進行跨源地不安全請求,請繼續該示例,新增"subdomain.example.com"
到此列表。該設定還支援子域,因此您可以新增".example.com"
,這樣允許從所有example.com
的子域進行訪問。
譯者注:有關同源策略的例子和繞過方法,請見 網友例項。
1.3 資料庫
DATABASE
預設值:{}
( 空字典)
包含Django要使用的所有資料庫的設定的字典。它是一個巢狀字典,其內容將資料庫別名對映到包含單個數據庫選項的字典。
必須配置default資料庫; 還可以指定任意數量的附加資料庫。
最簡單的設定檔案是使用SQLite進行單一資料庫設定。可以使用以下配置:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
}
}
連線到其他資料庫後端(如MySQL,Oracle或PostgreSQL)時,將需要其他連線引數。請參閱下面的ENGINE
設定,瞭解如何指定其他資料庫型別。這個例子適用於PostgreSQL:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql',
'NAME': 'mydatabase',
'USER': 'mydatabaseuser',
'PASSWORD': 'mypassword',
'HOST': '127.0.0.1',
'PORT': '5432',
}
}
可以使用以下內部選項來進行更復雜的配置:
ATOMIC_REQUESTS
預設: False
將其設定為True,將包裝資料庫中某個事務的每個檢視。請參閱將 事務繫結到HTTP請求。
AUTOCOMMIT
預設: True
如果要禁用Django的事務管理並實現自己的事務管理,請將此設定為False。
ENGINE
預設值:''
( 空字串)
要使用的資料庫後端。內建的資料庫後端是:
- ‘django.db.backends.postgresql’
- ‘django.db.backends.mysql’
- ‘django.db.backends.sqlite3’
- ‘django.db.backends.oracle’
您可以通過設定ENGINE為完全限定的路徑(即mypackage.backends.whatever
)來使用Django未附帶的資料庫後端 。
HOST
預設值:''
( 空字串)
連線到資料庫時使用哪個主機。空字串表示localhost。不與SQLite一起使用。
如果此值以正斜槓(/
)開頭並且您正在使用MySQL,則MySQL將通過Unix套接字連線到指定的socket。例如:
"HOST": '/var/run/mysql'
如果您正在使用MySQL並且此值不以正斜槓開頭,則假定此值為一個主機。
如果您正在使用PostgreSQL,預設情況下(空HOST),與資料庫的連線是通過UNIX域套接字(pg_hba.conf
中的‘local’行)完成的。如果您的UNIX域套接字不在標準位置,請使用與postgresql.conf
中相同的unix_socket_directoryfrom
值。如果要通過TCP套接字連線,請設定HOST為“localhost”或“127.0.0.1”(pg_hba.conf
中的‘host’行)。在Windows上,您應該始終定義HOST,因為UNIX域套接字不可用。
NAME
預設值:''
( 空字串)
要使用的資料庫的名稱。對於SQLite,它是資料庫檔案的完整路徑。指定路徑時,始終使用正斜槓,即使在Windows上(例如C:/homes/user/mysite/sqlite3.db
)。
CONN_MAX_AGE
預設: 0
資料庫連線的生命週期,以秒為單位。0表示在每個請求結束時關閉資料庫連線 - Django的歷史行為 - 設定為None無限持久連線。
OPTIONS
預設值:{}
( 空字典)
連線到資料庫時要使用的額外引數。可用引數因資料庫後端而異。
有關可用引數的一些資訊可以在 Database 後端文件中找到。有關更多資訊,請參閱後端模組自己的文件。
PASSWORD
預設值:''
( 空字串)
連線資料庫時使用的密碼。不與SQLite一起使用。
PORT
預設值:''
( 空字串)
連線到資料庫時使用的埠。空字串表示預設埠。不與SQLite一起使用。
TIME_ZONE
預設: None
表示儲存在此資料庫中的日期時間的字串(假設它不支援時區)或None
。該DATABASES內的這個TIME_ZONE
選項與後面的TIME_ZONE設定使用相同的值 。
這允許與以當地時間而不是UTC儲存日期時間的第三方資料庫進行互動。為避免DST更改出現問題,不應為Django管理的資料庫設定此選項。
如果USE_TZ=True
且資料庫不支援時區(如SQLite的,MySQL和Oracle)。這一句沒翻譯懂,自己看下(Django reads and writes datetimes in local time according to this option if it is set and in UTC if it isn’t
).
如果USE_TZ=True
且資料庫支援時區(如PostgreSQL),設定這個選項是個錯誤的。
如果USE_TZ=False
,設定這個選項是錯誤的。
DISABLE_SERVER_SIDE_CURSORS
預設: False
如果要禁用QuerySet.iterator()
中的伺服器端遊標,請將此設為True
。事務池和伺服器端遊標 描述了用例。
這是PostgreSQL特定的設定。
USER
預設值:''
( 空字串)
連線資料庫時使用的使用者名稱。不與SQLite一起使用。
TEST
預設值:{}
( 空字典)
測試資料庫的設定字典; 有關測試資料庫的建立和使用的更多詳細資訊,請參閱測試資料庫。
以下是測試資料庫配置的示例:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql',
'USER': 'mydatabaseuser',
'NAME': 'mydatabase',
'TEST': {
'NAME': 'mytestdatabase',
},
},
}
TEST字典中的以下鍵可用:
CHARSET
預設: None
用於建立測試資料庫的字符集編碼。此字串的值直接傳遞到資料庫,因此其格式是特定於後端的。
由PostgreSQL和MySQL後端支援。
COLLATION
預設: None
建立測試資料庫時要使用的排序順序。此值直接傳遞給後端,因此其格式是特定於後端的。
僅支援mysql後端(有關詳細資訊,請參閱MySQL手冊)。
DEPENDENCIES
預設值:['default']
,對於除了沒有依賴項的default之外的所有資料庫,。
資料庫的建立順序依賴關係。有關詳細資訊,請參閱有關控制測試資料庫的建立順序的文件。
MIRROR
預設: None
此資料庫在測試期間應映象的資料庫的別名。
此設定用於允許測試多個數據庫的主/副本(由某些資料庫稱為主/從)配置。有關詳細資訊,請參閱有關測試主/副本配置的文件 。
NAME
預設: None
執行測試元件時要使用的資料庫的名稱。
如果預設值(None)與SQLite資料庫引擎一起使用,則測試將使用記憶體駐留資料庫。對於所有其他資料庫引擎,測試資料庫將使用名稱'test_'
+ DATABASE_NAME
。
請參閱測試資料庫。
SERIALIZE
布林值,用於控制預設測試執行器是否在執行測試之前將資料庫序列化為記憶體中的JSON字串(如果沒有事務,則用於在測試之間恢復資料庫狀態)。如果沒有任何帶有serialized_rollback = True的測試類,可以將其設定為False
以加快建立時間。
TEMPLATE
這是PostgreSQL特定的設定。
用於建立測試資料庫的模板(例如’template0’)的名稱。
CREATE_DB
預設: True
這是Oracle特定的設定。
如果設定為False
,則測試表空間不會在測試開始時自動建立,也不會在結束時刪除。
CREATE_USER
預設: True
這是Oracle特定的設定。
如果設定為False
,則測試使用者將不會在測試開始時自動建立,並在結束時刪除。
USER
預設: None
這是Oracle特定的設定。
連線到將在執行測試時使用的Oracle資料庫的使用者名稱。如果沒有提供,Django將使用'test_'
+ USER
。
PASSWORD
預設: None
這是Oracle特定的設定。
連線到執行測試時將使用的Oracle資料庫的密碼。如果沒有提供,Django將生成一個隨機密碼。
TBLSPACE
預設: None
這是Oracle特定的設定。
執行測試時將使用的表空間的名稱。如果沒有提供,Django將使用'test_'
+ USER
。
TBLSPACE_TMP
預設: None
這是Oracle特定的設定。
執行測試時將使用的臨時表空間的名稱。如果沒有提供,Django將使用test_
+ USER
+ _temp
。
DATAFILE
預設: None
這是Oracle特定的設定。
用於TBLSPACE的資料檔案的名稱。如果沒有提供,Django將使用TBLSPACE + .dbf
。
DATAFILE_TMP
預設: None
這是Oracle特定的設定。
用於TBLSPACE_TMP
的資料檔案的名稱。如果沒有提供,Django將使用TBLSPACE_TMP + .dbf
。
DATAFILE_MAXSIZE
預設:'500M'
這是Oracle特定的設定。
DATAFILE允許增長到的最大大小。
DATAFILE_TMP_MAXSIZE
預設:'500M'
這是Oracle特定的設定。
DATAFILE_TMP允許增長到的最大大小。
DATAFILE_SIZE
Django 2.0 中的新功能:
預設:'50M'
這是Oracle特定的設定。
DATAFILE的初始大小。
DATAFILE_TMP_SIZE
Django 2.0 中的新功能:
預設: '50M'
這是Oracle特定的設定。
DATAFILE_TMP的初始大小。
DATAFILE_EXTSIZE
Django 2.0 中的新功能:
預設: '25M'
這是Oracle特定的設定。
當需要更多空間時,DATAFILE的擴充套件量。
DATAFILE_TMP_EXTSIZE
Django 2.0中的新功能:
預設:'25M'
這是Oracle特定的設定。
當需要更多空間時,DATAFILE_TMP的擴充套件量。
DATABASE_ROUTERS
預設值:[]
( 空列表)
將用於確定在執行資料庫查詢時使用哪個資料庫的路由器列表。
請參閱有關多資料庫配置中的自動資料庫路由的文件。
1.4 HTTP
DATA_UPLOAD_MAX_MEMORY_SIZE
預設值:2621440
( 即2.5 MB)。
引發SuspiciousOperation
(RequestDataTooBig)之前請求體可能的最大大小(以位元組為單位 )。檢查發生在碰到request.body
或request.POST
的時候, 並且不包括任何檔案上傳資料的大小來計算。您可以將其設定None
禁用檢查。預計會收到異常的使用大型表單帖子的應用程式應調整此設定。
請求資料量與處理請求所需的記憶體量相關,並填充GET和POST字典。如果不加以檢查,大請求可以用作拒絕服務攻擊向量。由於Web伺服器通常不執行深度請求檢查,因此無法在該級別執行類似檢查。
另見 FILE_UPLOAD_MAX_MEMORY_SIZE。
譯者例項:
a. 還是用我們在上面定義的form表單,提交一個2.52M大小的內容到input框中,瀏覽提提示連線被重置,服務端錯誤如下:
b. 修改DATA_UPLOAD_MAX_MEMORY_SIZE 大小為2.6M