---
title: "Django 1.1.4 版本发行说明"
version: 6.0
locale: zh-hans
source: https://docs.djangoproject.com/zh-hans/6.0/releases/1.1.4/
canonical: https://djangodocs.dev/zh-hans/6.0/releases/1.1.4/
---
# Django 1.1.4 版本发行说明

欢迎来到 Django 1.1.4 版本！

这是 Django 1.1 系列的第四个“错误修复”版本，改进了 Django 1.1 代码库的稳定性和性能。

除了一个例外，Django 1.1.4 与 Django 1.1.3 兼容。它还包含了一些修复和其他改进。对于当前使用或目标为 Django 1.1 的任何开发或部署，推荐升级到 Django 1.1.4 。

有关 1.1 分支中新功能、向后不兼容性和已弃用功能的详细信息，请参阅 [Django 1.1 版本发行说明](/zh-hans/6.0/releases/1.1/)。

## 不向后兼容的变更

### AJAX 请求的 CSRF 例外

Django 包含一个 CSRF 保护机制，它通过在传出的表单中插入一个令牌来实现。然后，中间件在表单提交时检查令牌的存在，并对其进行验证。

在 Django 1.2.5 之前，我们的 CSRF 保护对 AJAX 请求做了一个例外，基于以下原因：

- 许多 AJAX 工具包在使用 XMLHttpRequest 时会添加一个 X-Requested -With 头部。
- 浏览器对于 XMLHttpRequest 具有严格的同源策略。
- 在浏览器的上下文中，只有使用 XMLHttpRequest 才能添加这种自定义头部。

因此，为了方便使用，我们基于 X-Requested-With 头部，对看起来是 AJAX 请求的请求没有应用 CSRF 检查。 Ruby on Rails Web 框架也有类似的例外情况。

最近，Google 的工程师向 Ruby on Rails 开发团队的成员们提醒了一种结合浏览器插件和重定向的技术，可以允许攻击者在向任何网站发出请求时提供自定义的 HTTP 头信息。这可以使伪造的请求看起来像是 AJAX 请求，从而破坏了 CSRF 保护机制，因为它信任 AJAX 请求具有同源性质。

Rails 团队的 Michael Koziarski 向我们提出了这个问题，我们能够制作出一个概念验证，证明了 Django 的 CSRF 处理也存在同样的漏洞。

为了解决这个问题，Django 现在将对所有请求应用完整的 CSRF 验证，无论它们看起来是否来自 AJAX 。从技术上讲，这是不兼容的，但在这种情况下，安全风险被认为超过了兼容性问题。

此外，Django 现在将接受自定义 HTTP 头 X-CSRFTOKEN 中的 CSRF 令牌，以及表单提交本身中的令牌，以便与流行的 JavaScript 工具包一起使用，这些工具包允许在所有 AJAX 请求中插入自定义头。这样做是为了方便使用。

请参阅 [CSRF 文档中的示例 jQuery 代码](/zh-hans/6.0/howto/csrf/#csrf-ajax)，该代码演示了这个技巧，确保您查看的是适用于您的 Django 版本的文档，因为一些较旧版本的 Django 需要不同的确切代码。