我有一個使用 Gunicorn 和 Nginx 的 dockerized Django 應用程式。使用本地主機登錄管理頁面時，沒有出現CSRF錯誤。當使用 Route 53 作為代理服務器（https 重定向到 http）在 Amazon EC2 上運行 docker 時，我在登錄時收到 CSRF 錯誤。我在 settings.py 檔案中注意到以下內容（我添加了 SECURE_SSL_REDIRECT = False 但它沒有效果）：
ALLOWED_HOSTS = ['localhost', '.website_name.ca']
SECURE_SSL_REDIRECT = False
# Application definition
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'The6ixDjango.apps.The6IxdjangoConfig',
]
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',
]
鑒于我在前端有 Route 53，洗掉 MIDDLEWARE 串列中的 csrf 中間件參考是否“安全”？
uj5u.com熱心網友回復：
由于您使用的是將 https 請求轉換為 http 的代理，因此您需要將 Django 配置為允許來自不同方案（自 Django 4.0 起）的POST 請求，方法是將其添加到settings.py：
CSRF_TRUSTED_ORIGINS = ["https://yourdomain.com", "https://www.yourdomain.com"]
如果這不能解決您的問題，您可以暫時DEBUG = True在生產中設定并重試。在錯誤頁面上，您將看到“失敗原因”，您可以在此處發布。（您寫了“登錄時的 CSRF 錯誤”，但有 9 種可能的錯誤，了解實際錯誤會很有用。）
SECURE_SSL_REDIRECTFalse確實應該是（因為 Route 53 會為您處理重定向）但False它是默認值，因此您可以簡單地省略該SECURE_SSL_REDIRECT設定。
從串列中洗掉絕對不安全。Route 53 不會為您提供對 CSRF 攻擊的等效保護。CsrfViewMiddlewareMIDDLEWARE
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/403236.html
標籤：