Django 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 版本发行说明。
不向后兼容的变更
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 代码，该代码演示了这个技巧，确保您查看的是适用于您的 Django 版本的文档，因为一些较旧版本的 Django 需要不同的确切代码。