Django 开发服务器的本地和远程机器 cookie 传递有什么区别?
我有一个 Django 1.2.5(稳定版本)网站,正在 Ubuntu 10.10 机器上开发和测试。开发盒位于 LAN 上,其中有一些 Windows 计算机也需要能够查看和测试该站点。到目前为止,我只是想分享管理员。
该网站在开发盒上运行良好,当使用以下命令启动开发服务器时,可以在 127.0.0.1:8080/admin 或 192.168.17.165:8080/admin (开发盒的 LAN IP)上运行./manage.py runserver 和 ./manage.py runserver 192.168.17.165:8080 分别。但是,当 Windows 计算机尝试访问位于 192.168.17.165:8080/admin 的服务器时,管理员登录页面加载得很好,因此几乎设置正确,但是当验证的用户名和密码为输入并按下提交按钮,帖子失败并返回以下错误:(
Forbidden (403) CSRF verification failed. Request aborted.
Reason given for failure:
No CSRF or session cookie.
与@thomallen的帖子非常相似)
以下是我已经检查过的一些内容,但似乎没有任何效果:
我知道 login.html 模板添加了 {% csrf_token %} 令牌。当我查看页面的源代码时,标签
{% block content %}
{% if error_message %}
<p class="errornote">{{ error_message }}</p>
{% endif %}
<div id="content-main">
<form action="{{ app_path }}" method="post" id="login-form">{% csrf_token %}
<div class="form-row">
<label for="id_username">{% trans 'Username:' %}</label> <input type="text" name="username" id="id_username" />
</div>
是存在的。 (stock admin login.html)
我弄乱了所有中间件行的顺序,如此处所示 http://josh.gourneau.com/blog/2010/02/17/django-12-csrf-verification-failed/。没有什么。 这就是我所拥有的:
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.middleware.csrf.CsrfResponseMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware', )
我想也许我应该搞乱这些,但它似乎没有帮助
SESSION_COOKIE_DOMAIN = '192.168.17.165'
CSRF_COOKIE_DOMAIN = '192.168.17.165'
清除所有其他cookie和网络历史记录。关闭了防火墙。
我目前的怀疑: 在开发盒(有效的那个)上,Firefox 显示存在 2 个 cookie,sessionid 和 csrftoken。 Windows 盒子似乎没有获得这些令牌。我在两台机器上使用 Firefox Live HTTP headers 插件查看了 HTTP headers。 Linux 盒子(与服务器相同)获取:
Set-Cookie: csrftoken=83bae579460e9d123d9d904f4e2ef4d5; Max-Age=31449600; Path=/
Set-Cookie: sessionid=ec2b472837318347f6e6c8243f9e0afd; expires=Sat, 02-Apr-2011 04:29:46 GMT; Max-Age=1209600; Path=/
Windows 盒子获取非常相似的信息,但 cookie 的 Max-Age 设置为 0 (Max-Age=0)。此后,Windows 机器将不再存储 cookie。根据 ietf.org/rfc/rfc2109.txt,这显然会立即终止会话。我确实尝试将 SESSION_COOKIE_AGE 设置为 10000 但没有成功。
我需要做什么才能让 Django 开发服务器将有效的 cookie 发送到远程计算机?我不能是唯一的一个......
其他类似的 stackoverflow 帖子和链接看起来很有希望但不起作用: 为什么 Django 管理员登录会给我 403 CSRF 错误?< /a> Django 将 CSRF 令牌输出为对象而不是值
I已阅读所有文档并请几个人帮助我查看,但我不知道可能导致此问题的原因。我确信有一些方法可以禁用 CSRF 作为解决方法,但这不应该起作用吗?
I have a Django 1.2.5 (stable release) site that is being developed and tested on a Ubuntu 10.10 machine. The dev box is on a LAN with some Windows machines that need to be able to view and test the site as well. So far, it is just the admin that I am trying to share.
The site works great on the dev box and can be run on 127.0.0.1:8080/admin or 192.168.17.165:8080/admin (the dev box's LAN IP) when starting the development server with the commands ./manage.py runserver and ./manage.py runserver 192.168.17.165:8080 respectively. However, when the windows machine tries to reach the server at 192.168.17.165:8080/admin the admin login page loads just fine, so things are almost set up correctly, but when the verified username and password are entered and the submit button is pressed, the post fails and the following error is returned:
Forbidden (403) CSRF verification failed. Request aborted.
Reason given for failure:
No CSRF or session cookie.
(very similar to @thomallen's post)
Here are some things that I have already checked that don't seem to have any effect:
I know that the login.html template has the {% csrf_token %} token added. When I view the source of the page, the tag
{% block content %}
{% if error_message %}
<p class="errornote">{{ error_message }}</p>
{% endif %}
<div id="content-main">
<form action="{{ app_path }}" method="post" id="login-form">{% csrf_token %}
<div class="form-row">
<label for="id_username">{% trans 'Username:' %}</label> <input type="text" name="username" id="id_username" />
</div>
is present. (stock admin login.html)
I have messed with the order of all the Middleware lines as seen here http://josh.gourneau.com/blog/2010/02/17/django-12-csrf-verification-failed/. Nothing.
Here is what I have:
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.middleware.csrf.CsrfResponseMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware', )
I thought maybe I should mess with these but it didn't seem to help
SESSION_COOKIE_DOMAIN = '192.168.17.165'
CSRF_COOKIE_DOMAIN = '192.168.17.165'
Cleared out all other cookies and web history. Turned off firewall.
My current suspicion:
On the dev box (the one that works), Firefox shows 2 cookies present, sessionid and csrftoken. The windows boxes do not seem to be getting these tokens. I looked into the HTTP headers using the Firefox Live HTTP headers plugin on both machines. The linux box (same as server) gets:
Set-Cookie: csrftoken=83bae579460e9d123d9d904f4e2ef4d5; Max-Age=31449600; Path=/
Set-Cookie: sessionid=ec2b472837318347f6e6c8243f9e0afd; expires=Sat, 02-Apr-2011 04:29:46 GMT; Max-Age=1209600; Path=/
The windows box gets very similar info, but the Max-Age of the cookie is set to 0 (Max-Age=0). After this, the windows machines don't store the cookies. This apparently kills the session immediately according to ietf.org/rfc/rfc2109.txt. I did try setting SESSION_COOKIE_AGE to 10000 but it didn't take.
What do I need to do to get the stock Django development server to send valid cookies to a remote machine? I can't be the only one...
Other similar stackoverflow posts and links that seemed promising but didn't work:
Why is Django admin login giving me 403 CSRF error?
Django outputs CSRF token as object instead of value
I have read all the documentation and had a couple people help me look at it and I have no clue what could be causing this. I am sure there are ways to disable CSRF as a workaround, but shouldn't this be working?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
结果发现这是一个没有关闭的辅助软件。 CA Anti Virus 有一个单独的进程正在运行,该进程会在事后阻止 cookie。
It turned out to be a secondary piece of software that was not turned off. CA Anti Virus had a separate process running that was blocking cookies after the fact.