更新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})
我CSRF cookie not set
从Django 得到了一个错误,但这不是因为我忘了{% csrf_token %}
在我的模板中包含它.
这是我观察到的:
在里面Request Header
,cookie
价值是:
csrftoken=yNG8ZmSI4tr2xTLoE9bys8JbSuu9SD34;
在模板中:
在我安装在chrome上的cookie插件中,实际的csrf cookie值设置为:
9CVlFSxOo0xiYykIxRmvbWyN5iEUHnPB
在里面Request Header
,cookie
价值是:
csrftoken=9CVlFSxOo0xiYykIxRmvbWyN5iEUHnPB;
在模板中:
在我安装在chrome上的cookie插件中,实际的csrf cookie值设置为:
Y534sU40S8iTubSVGjjh9KQl0FXesVsC
从上面的示例中可以看出,其中的cookie值Request Header
与csrfmiddlewaretoken
表单中的实际值和设置的实际cookie值不同.
当前请求的request header's
cookie值与下一个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
.
我以前遇到过这个问题,我可以清除所有浏览器cookie,网站也能正常运行.但是这个问题最终会再次出现,所以我真的希望有人可以帮助我(我可能只是在某个地方犯了一个非常愚蠢的错误).
最初,我认为我在覆盖django.contrib.auth.view
页面时犯了一些错误,所以我编写了自己的登录页面处理程序,但仍然会导致问题.
这是我的登录模板的核心部分:
{% block content %} ...... {% endblock %}
在Linux机器上,我有一个nginx服务器设置作为反向代理,它将端口80上的请求定向到8001,并且我正在运行服务器./manage runserver localhost:8001
这是我在设置方面可以想到的唯一区别.否则,所有源代码和设置文件都是相同的.
我开始删除cookie但不是全部删除,这是我在删除它之前看到的:
我删除了除了djdt
和之外的所有cookie csrftoken
,然后页面工作了.被删除的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
由于网站现在运行,我所有的都是五个饼干,而不是像上图中的14个:
问题在于:您不能拥有一个cookie,其中哪个键包含字符'['或']'
我在@Todor 链接后发现了解决方案,然后我发现了这个SO帖子.基本上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中得到修复,只需要等待发布
作为这篇文章的结果,我向 Django 提交了一份错误报告.我们将看看它是否会在将来的版本中修复.