Django 的 ModSecurity 错误
我尝试通过在 DreamHost 上使用 fb.py 制作的 Facebook 应用程序 (iframe) 访问 Django 页面，但不断收到内部服务器错误。
查看错误日志，这是我看到的：
ModSecurity：输出过滤器：无法读取存储桶（rc 104）：连接被对等方重置
我认为这与 POST 请求有关。大约一年前，其他人在许多论坛上询问过此错误，但无济于事：
ModSecurity：输出过滤器：无法读取存储桶（rc 104）：连接由对等方重置
我能找到的所有搜索都是 http://www.modsecurity.org：
“当 mod_security 拒绝此类请求时，它会沿着输出过滤器链发送一个带有例如代码 403 的错误存储桶，并保持 r->status 不变（例如 500）。”
有什么想法吗？谢谢！
I'm trying to access a Django page through a Facebook App (iframe) I made using fb.py on DreamHost and I keep getting an internal server error.
Looking in the error logs, this is what I see:
ModSecurity: Output filter: Failed to read bucket (rc 104): Connection reset by peer
I think it just has to do with the POST request. Somebody else asked about this error on a number of forums almost a year ago, to no avail:
ModSecurity: Output filter: Failed to read bucket (rc 104): Connection reset by peer
All I could find searching was this at http://www.modsecurity.org:
"When mod_security denies such a request, it sends an error bucket with e.g. code 403 down the output filter chain, leaving r->status as is (e.g. 500)."
Any ideas? Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您是否按照 https://docs.djangoproject.com 实施了 CSRF 保护/en/dev/ref/contrib/csrf/#ajax ？
请注意与您正在使用的 Django 版本进行交叉检查。
Have you implemented CSRF protection as per https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax ?
Note to cross-check with the version of Django you are using.
所以我花了太多时间试图解决这个问题。我已经解决了一个（有点糟糕）的解决方法：将
{% csrf_token %}添加到模板中的任何位置（我假设您传入了context_instance=RequestContext(request )参数到你的render_to_response或其他）。我认为发生的情况是 cookie 实际上没有被设置（这可以通过检查任何浏览器的开发工具中的 cookie 来确认）。将上述代码添加到您的模板中会强制执行此操作。我有一种感觉，这可能会在 Django 的更高版本中得到解决，并且似乎 1.4+ 版本有明显的修复（例如，请参阅 此处）。不幸的是，dreamhost 让我们只能使用 1.2.3，所以我们只能凑合着用。
So I've spent way too much time trying to figure this out. I've settled on a (slightly shitty) work-around: add
{% csrf_token %}to any place in your template (I'm assuming you passed in thecontext_instance=RequestContext(request)argument to yourrender_to_responseor whatever).I think what is happening is that the cookie doesn't actually get set (this can be confirmed through inspecting the cookies in any browser's development tools). Adding the above code to your template forces this. I have a feeling that this may be remedied in later versions of Django, and it seems as though there are obvious fixes for 1.4+ (e.g., see here). Unfortunately dreamhost has stuck us with 1.2.3, so we need to make do.