更新7-18:
这是我的代理服务器的nginx配置:
server {
listen 80;
server_name blah.com; # the blah is intentional
access_log /home/cheng/logs/access.log;
error_log /home/cheng/logs/error.log;
location / {
proxy_pass http://127.0.0.1:8001;
}
location /static {
alias /home/cheng/diandi/staticfiles;
}
location /images {
alias /home/cheng/diandi/images;
}
client_max_body_size 10M;
}
以下是nginx.conf
:
user www-data;
worker_processes 4;
pid /var/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;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip_disable "msie6";
# Enable Gzip compressed.
gzip on;
# Enable compression both for HTTP/1.0 and HTTP/1.1.
gzip_http_version 1.1;
# Compression level (1-9).
# 5 is a perfect compromise between size and cpu usage, offering about
# 75% reduction for most ascii files (almost identical to level 9).
gzip_comp_level 5;
# Don't compress anything that's already small and unlikely to shrink much
# if at all (the default is 20 bytes, which is bad as that usually leads to
# larger files after gzipping).
gzip_min_length 256;
# Compress data even for clients that are connecting to us via proxies,
# identified by the "Via" header (required for CloudFront).
gzip_proxied any;
# Tell proxies to cache both the gzipped and regular version of a resource
# whenever the client's Accept-Encoding capabilities header varies;
# Avoids the issue where a non-gzip capable client (which is extremely rare
# today) would display gibberish if their proxy gave them the gzipped version.
gzip_vary on;
# Compress all output labeled with one of the following MIME-types.
gzip_types
application/atom+xml
application/javascript
application/json
application/rss+xml
application/vnd.ms-fontobject
application/x-font-ttf
application/x-web-app-manifest+json
application/xhtml+xml
application/xml
application/x-javascript
font/opentype
image/svg+xml
image/x-icon
text/css
text/plain
text/javascript
text/js
text/x-component;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
更新7-15:
将代码复制到linux机器时,我只是替换了原始的源代码文件,但没有删除旧的.pyc文件,我认为这些文件不会造成麻烦吗?
以下是视图代码:
from django.contrib.auth import authenticate, login
from django.http import HttpResponseRedirect
from django.core.urlresolvers import reverse
from django.shortcuts import render
def login_view(request):
if request.method == 'POST':
username = request.POST['username']
password = request.POST['password']
user = authenticate(username=username, password=password)
next_url = request.POST['next']
if user is not None:
if user.is_active:
login(request, user)
if next_url:
return HttpResponseRedirect(next_url)
return HttpResponseRedirect(reverse('diandi:list'))
else:
form = {'errors': True}
return render(request, 'registration/login.html', {'form': form})
else:
form = {'errors': False}
return render(request, 'registration/login.html', {'form': form})
我从Django收到了CSRF cookie not set
错误之一,但这不是因为我忘记在我的模板中包含{% csrf_token %}
。
这是我观察到的:
在Request Header
内,cookie
值为:
csrftoken=yNG8ZmSI4tr2xTLoE9bys8JbSuu9SD34;
在模板中:
<input type="hidden" name="csrfmiddlewaretoken" value="9CVlFSxOo0xiYykIxRmvbWyN5iEUHnPB">
在我安装在chrome上的cookie插件中,实际的csrf cookie值设置为:
9CVlFSxOo0xiYykIxRmvbWyN5iEUHnPB
在Request Header
内,cookie
值为:
csrftoken=9CVlFSxOo0xiYykIxRmvbWyN5iEUHnPB;
在模板中:
<input type="hidden" name="csrfmiddlewaretoken" value="Y534sU40S8iTubSVGjjh9KQl0FXesVsC">
在我安装在chrome上的cookie插件中,实际的csrf cookie值设置为:
Y534sU40S8iTubSVGjjh9KQl0FXesVsC
从上面的示例中可以看出,Request Header
中的Cookie值与表单中的实际csrfmiddlewaretoken
和设置的实际Cookie值不同。
当前请求的Cookie值与下一个request header's
Cookie值匹配。
为了帮助调试,这是我的`settings.py:
的一部分DJANGO_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
)
THIRD_PARTY_APPS = (
'compressor',
'crispy_forms',
'django_extensions',
'floppyforms',
'multiselectfield',
'admin_highcharts',
)
LOCAL_APPS = (
'diandi_project',
'uer_application',
)
INSTALLED_APPS = DJANGO_APPS + THIRD_PARTY_APPS + LOCAL_APPS
MIDDLEWARE_CLASSES = (
'django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
)
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [str(ROOT_DIR.path('templates'))],
'APP_DIRS': True,
'OPTIONS': {
'context_processors': [
'django.template.context_processors.media',
'django.template.context_processors.debug',
'django.template.context_processors.request',
'django.contrib.auth.context_processors.auth',
'django.contrib.messages.context_processors.messages',
],
},
},
]
我正在使用Django 1.9.5
和python 2.7.10
。
我遇到this problem before,我可以清除所有浏览器Cookie,网站也能正常运行。但是这个问题最终会再次出现,所以我真的希望有人可以帮助我(我可能只是在某个地方犯了一个非常愚蠢的错误)。
最初,我认为在覆盖django.contrib.auth.view
页面时犯了一些错误,所以我编写了自己的登录页面处理程序,但仍然会导致问题。
以下是我的登录模板的核心部分:
{% block content %}
...
<form method="post" action="{% url 'login' %}">
{% csrf_token %}
<div class="form-group">
<label for="username">username</label>
<input type="text" class="form-control" id="id_username" name="username">
</div>
<div class="form-group">
<label for="password">password</label>
<input type="password" class="form-control" id="id_password" name="password">
</div>
<input type="submit" class="btn btn-default" value="login" />
<input type="hidden" id="next" name="next" value="" />
</form>
...
{% endblock %}
在Linux机器上,我有一个nginx服务器设置作为反向代理,它将端口80上的请求定向到8001,我使用./manage runserver localhost:8001
运行服务器这是我能想到的唯一区别安装否则,所有源代码和设置文件都是相同的。
我开始删除cookie但不是全部删除,这是我在删除之前看到的:
我删除了djdt
和csrftoken
以外的所有Cookie,然后页面正常工作。被删除的cookie是否会以某种方式超过某些限制,从而阻止列表中的csrftoken被设置?
以下是请求标题中上图中的Cookie值:
Cookie:PSTM=1466561622; BIDUPSID=6D0DDB8084625F2CEB7B9D0F14F93391; BAIDUID=326150BF5A6DFC69B6CFEBD67CA7A18B:FG=1; BDSFRCVID=Fm8sJeC62leqR8bRqWS1u8KOKg9JUZOTH6ao6BQjXAcTew_mbPF_EG0PJOlQpYD-hEb5ogKK0mOTHvbP; H_BDCLCKID_SF=tJPqoCtKtCvbfP0k-tcH244HqxbXq-r8fT7Z0lOnMp05EnnjKl5M3qKOqJraJJ585Gbb5tOhaKj-VDO_e6u-e55LjaRh2PcM2TPXQ458K4__Hn7zep0aqJtpbt-qJjbOfmQBbfoDQCTDfho5b63JyTLqLq5nBT5Ka26WVpQEQM5c8hje-4bMXPkkQN3T-TJQL6RkKTCyyx3cDn3oyToVXp0njGoTqj-eJbA8_CtQbPoHHnvNKCTV-JDthlbLetJyaR3lWCnbWJ5TMCo1bJQCe-DwKJJgJRLOW2Oi0KTFQxccShPC-tP-Ll_qW-Q2LPQfXKjabpQ73l02VhcOhhQ2Wf3DM-oat4RMW20jWl7mWPQDVKcnK4-Xj533DHjP; BDUSS=5TNmRvZnh2eUFXZDA5WXI5UG1HaXYwbzItaWt3SW5adjE1Nn5XbUVoWHZuYXBYQVFBQUFBJCQAAAAAAAAAAAEAAAC0JtydAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO8Qg1fvEINXSU; Hm_lvt_a7708f393bfa27123a1551fef4551f7a=1468229606; Hm_lpvt_a7708f393bfa27123a1551fef4551f7a=1468229739; BDRCVFR[feWj1Vr5u3D]=I67x6TjHwwYf0; BDRCVFR[dG2JNJb_ajR]=mk3SLVN4HKm; BDRCVFR[-pGxjrCMryR]=mk3SLVN4HKm; cflag=15%3A3; H_PS_PSSID=1424_20515_13289_20536_20416_19861_14994_11792; csrftoken=xUgSHybzHeIwusN0GvMgB1ATeRrPgcV1
由于网站现在正常运行,我所拥有的只有5个cookie而不是14个,如上图所示:
答案 0 :(得分:17)
以下是问题:您不能拥有一个cookie,其中哪个键包含字符'['或']'
我在@Todor link之后发现了解决方案,然后我发现了SO post。基本上python 2.7.x中有一个错误,它不会在值中解析带有']'的cookie。该错误已在2.7.10中修复。
我认为只是确认这个问题会很好。所以我挖掘了所有的cookie并找到了一个具有以下键/值的cookie:
key: BDRCVFR[feWj1Vr5u3D]
val: I67x6TjHwwYf0
所以我在本地插入了以下cookie并提交给服务器:
key: test
val: BDRCVFR[feWj1Vr5u3D]
登录页面有效,这意味着2.7.10确实修复了错误。
但后来我意识到方括号实际上是键值而不是值,所以我做了以下测试:
key: [
val: I67x6TjHwwYf0
和
key:]
val: I67x6TjHwwYf0
两个cookie都会破坏登录过程并显示django:
CSRF cookie not set
因此,它所依赖的django或python库无法正确解析名称中带方括号的cookie。如果有人知道我应该在哪里提交这个bug,请告诉我(django或python)。
我要感谢所有在OP中发表评论的人:@raphv,@ trinchet,@ Phipip,@ YPCrumble,@ PeterBrittain和@Todor。非常感谢你们和我一起调试!
这个错误在Django 1.10中得到修复,只需要等待发布