您好,登錄后才能下訂單哦!
小編給大家分享一下怎么解決Django提交表單報錯:CSRF token missing or incorrect的問題,相信大部分人都還不怎么了解,因此分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后大有收獲,下面讓我們一起去了解一下吧!
1、在Django提交表單時報錯:Django提交表單報錯:
CSRF token missing or incorrect
具體報錯頁面如下:
2、有道詞典翻譯后如下:
通常,當存在真正的跨站點請求偽造時,或者Django的CSRF機制沒有被正確使用時,就會出現這種情況。至于郵遞表格,你須確保:
您的瀏覽器正在接受cookie。
視圖函數將一個請求傳遞給模板的呈現方法。
在模板中,每個POST表單中都有一個{% csrf_token %}模板標記,目標是一個內部URL。
如果您沒有使用CsrfViewMiddleware,那么您必須在任何使用csrf_token模板標簽的視圖以及那些接受POST數據的視圖上使用csrf_protect。
該表單有一個有效的CSRF令牌。在登錄另一個瀏覽器選項卡或登錄后單擊back按鈕之后,您可能需要使用表單重新加載頁面,因為登錄后令牌會旋轉。
您將看到這個頁面的幫助部分,因為在Django設置文件中有DEBUG = True。將其更改為False,將只顯示初始錯誤消息。
您可以使用CSRF_FAILURE_VIEW設置自定義這個頁面。
3、解決辦法:
(1)、確定項目底下的settings.py文件,是否存在django.middleware.csrf.CsrfViewMiddleware:
MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', ]
(2)、如果確定settings.py文件有配置了,還是報錯,就要在form表單底下加一行代碼:
{% csrf_token %}
這樣應該就不會報上面錯誤了,以上內容僅供學習參考,謝謝!
補充知識:Django中csrf token驗證原理
我多年沒維護的博客園,有一篇初學Django時的筆記,記錄了關于django-csrftoekn使用筆記,當時幾乎是照抄官網的使用示例,后來工作全是用的flask。博客園也沒有維護。直到我的博客收到了如下評論,確實把我給問倒了,而且我也仔細研究了這個問題。
1. Django是怎么驗證csrfmiddlewaretoken合法性的?
2. 每次刷新頁面的時候<input>中的csrf的value都會更新,每次重復登錄的時候cookie的csrf令牌都會刷新,那么這兩個csrf-token有什么區別?
image.png
CSRF(Cross Site Request Forgery protection),中文簡稱跨站請求偽造。
django 第一次響應來自某個客戶端的請求時,會在服務器端隨機生成一個 token,把這個 token 放在 cookie 里。然后每次 POST 請求都會帶上這個 token,
這樣就能避免被 CSRF 攻擊。
這樣子看起來似乎沒毛病,但是評論中的第三個問題,每次刷新頁面,form表單中的token都會刷新,而cookie中的token卻只在每次登錄時刷新。我對csrftoken的驗證方式起了疑問,后來看了一段官方文檔的解釋。
When validating the ‘csrfmiddlewaretoken' field value, only the secret, not the full token, is compared with the secret in the cookie value. This allows the use of ever-changing tokens. While each request may use its own token, the secret remains common to all.
This check is done by CsrfViewMiddleware.
官方文檔中說到,檢驗token時,只比較secret是否和cookie中的secret值一樣,而不是比較整個token。
我又有疑問了,同一次登錄,form表單中的token每次都會變,而cookie中的token不便,django把那個salt存儲在哪里才能保證驗證通過呢。
直到看到源碼。
def _compare_salted_tokens(request_csrf_token, csrf_token): # Assume both arguments are sanitized -- that is, strings of # length CSRF_TOKEN_LENGTH, all CSRF_ALLOWED_CHARS. return constant_time_compare( _unsalt_cipher_token(request_csrf_token), _unsalt_cipher_token(csrf_token), ) def _unsalt_cipher_token(token): """ Given a token (assumed to be a string of CSRF_ALLOWED_CHARS, of length CSRF_TOKEN_LENGTH, and that its first half is a salt), use it to decrypt the second half to produce the original secret. """ salt = token[:CSRF_SECRET_LENGTH] token = token[CSRF_SECRET_LENGTH:] chars = CSRF_ALLOWED_CHARS pairs = zip((chars.index(x) for x in token), (chars.index(x) for x in salt)) secret = ''.join(chars[x - y] for x, y in pairs) # Note negative values are ok return secret
token字符串的前32位是salt, 后面是加密后的token, 通過salt能解密出唯一的secret。
django會驗證表單中的token和cookie中token是否能解出同樣的secret,secret一樣則本次請求合法。
同樣也不難解釋,為什么ajax請求時,需要從cookie中拿取token添加到請求頭中。
網上有不少關于django csrf token驗證原理的文章都是錯的,是因為他們根本不知道csrf-token的結構組成,我也是卡在第三條評論那.然后看了官方文檔,和CsrfViewMiddleware中間件源碼然后才恍然大悟。
以上是“怎么解決Django提交表單報錯:CSRF token missing or incorrect的問題”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。