我开始了一个新的Django 1.11项目,其中包含一个应用程序,一个模型和一个管理面板。在当地,一切正常。当我将其部署到Amazon EC2并尝试登录管理面板时,我得到403(CSRF验证失败。请求中止。)。我在调试日志中看到了这一点:
[WARNING] 2017-05-21 11:23:52,142 csrf 14263 140377210439424 Forbidden (Referer checking failed - Referer is insecure while host is secure.): /admin/login/
我使用Chrome的网络实用程序检查了请求,我发现在我的请求标题中我有:
Cookie:csrftoken=hFhzOJPMOhkNWWWfRtlMOEum9jXV8XXWnOtw3OwZm2En9JUqYRVq632xyZfwSpzU
在我的表单数据中我有:
csrfmiddlewaretoken:RHNpPfOHhg42FZnXmn9PZgNm3bN40C41XQZm4kvUP1oCSMl8tLJthFlxsR5FK4GZ
这两者应该相同吗?根据我的理解,他们这样做,但是当我在我的本地环境中尝试相同时,我发现它们也不一样,但是它工作正常,我在请求中发送的响应标头中得到相同的令牌标题,所以我认为它们不需要完全相同?注意:我目前没有安全连接(https),但在修复后将继续使用。
我已经尝试/检查了以下内容:
CSRF_COOKIE_DOMAIN
(https://stackoverflow.com/a/42115353/1469465)CSRF_COOKIE_SECURE
,因此False
(https://stackoverflow.com/a/29574563/1469465)ALLOWED_HOSTS
我在SO上发现的其他答案提到你需要在表单中做一些事情,但这是Django框架中的一个表单。
其他信息
来自/etc/nginx/nginx.conf
的我的nginx配置:
user www-data;
worker_processes auto;
pid /run/nginx.pid;
events {
worker_connections 768;
# multi_accept on;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# SSL Settings
##
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip on;
gzip_disable "msie6";
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
来自/etc/nginx/sites-enabled/MyDjangoService
的我的网站特定配置:
upstream MyDjangoService_wsgi_server {
# fail_timeout=0 means we always retry an upstream even if it failed
# to return a good HTTP response (in case the Unicorn master nukes a
# single worker for timing out).
server unix:/webapps/MyDjangoService/run/gunicorn.sock fail_timeout=0;
}
server {
listen 80;
server_name MyDjangoService;
client_max_body_size 4G;
access_log /webapps/MyDjangoService/logs/nginx_access.log;
error_log /webapps/MyDjangoService/logs/nginx_error.log;
location /static/ {
alias /webapps/MyDjangoService/static/;
}
location /media/ {
alias /webapps/MyDjangoService/media/;
}
location / {
if (-f /webapps/MyDjangoService/maintenance_on.html) {
return 503;
}
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header Host $http_host;
proxy_redirect off;
# Try to serve static files from nginx, no point in making an
# *application* server like Unicorn/Rainbows! serve static files.
if (!-f $request_filename) {
proxy_pass http://MyDjangoService_wsgi_server;
break;
}
}
# Error pages
error_page 500 502 504 /500.html;
location = /500.html {
root /webapps/MyDjangoService/django/src/MyDjangoService/templates/;
}
error_page 503 /maintenance_on.html;
location = /maintenance_on.html {
root /webapps/MyDjangoService/;
}
}
答案 0 :(得分:2)
您的问题在以下一行:
proxy_set_header X-Forwarded-Proto https;
在此,您无条件地将X-Forwarded-Proto
标头设置为值https
。您的WSGI服务器会将此解释为表示您的站点在https后面运行。 Django然后进行严格的引用检查,并发现引用者域中的协议是http而不是https。因为这可能是一个安全问题,Django会拒绝该请求。
您应该删除此行,或更改它以使用正确的值。您可以使用$scheme
变量:
proxy_set_header X-Forwarded-Proto $scheme;
答案 1 :(得分:0)
如果出于某种原因您希望或需要无条件转发https并且您正在本地主机上工作,请通过放置
来克服管理页面上的CSRF错误CSRF_TRUSTED_ORIGINS = ["127.0.0.1"]
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
在settings.py文件中,并在浏览器中使用https://127.0.0.1:443/admin