欢迎来到Django 1.2.5！
这是Django1.2系列中的第五个“错误修复”版本，提高了Django1.2代码库的稳定性和性能。
除了四个例外，django 1.2.5与django 1.2.4保持向后兼容性。它还包含许多修复和其他改进。Django 1.2.5是当前使用或针对Django 1.2的任何开发或部署的建议升级。
有关1.2分支中新功能、向后不兼容和不推荐使用的功能的完整详细信息，请参见 Django 1.2发行说明 .
Django包括一个CSRF保护机制，利用插入到输出表单中的令牌。然后中间件在表单提交时检查令牌是否存在，并对其进行验证。
在Django 1.2.5之前，我们的CSRF保护在以下基础上对Ajax请求进行了例外处理：
许多Ajax工具包在使用xmlhttpRequest时添加了一个x-requested-with头。
浏览器对xmlhttpRequest有严格的相同来源策略。
在浏览器上下文中，可以添加这种性质的自定义头的唯一方法是使用xmlhttpRequest。
因此，为了便于使用，我们没有对基于x-requested-with头的看起来是Ajax的请求应用CSRF检查。RubyonRailsWeb框架也有类似的例外。
最近，谷歌的工程师让RubyonRails开发团队的成员意识到浏览器插件和重定向的结合，这使得攻击者能够在任何网站的请求中提供自定义HTTP头。这可以使伪造的请求看起来像是Ajax请求，从而破坏信任Ajax请求相同来源性质的CSRF保护。
Rails团队的Michael Koziarski让我们注意到了这一点，并且我们能够提供一个概念证明，证明Django的CSRF处理中同样存在漏洞。
为了解决这个问题，Django现在将对所有请求应用完整的CSRF验证，而不考虑明显的Ajax来源。这在技术上是向后不兼容的，但是在这种情况下，安全风险已经被判断为大于兼容性问题。
此外，Django现在将接受自定义HTTP头x-csrf token以及表单提交本身中的csrf令牌，以便与流行的javascript工具包一起使用，后者允许将自定义头插入所有Ajax请求中。
请看 CSRF docs for example jQuery code 这演示了这种技术，确保您正在查看Django版本的文档，因为某些旧版本的Django所需的确切代码是不同的。
在早期的django版本中，当包含 FileField 被删除， FileField 它自己也从后端存储器中删除了该文件。这为几个可能严重的数据丢失场景打开了大门，包括回滚事务和引用同一文件的不同模型上的字段。在Django 1.2.5中， FileField 永远不会从后端存储中删除文件。如果需要清理孤立文件，则需要自己处理（例如，使用自定义管理命令，可以手动运行，也可以通过cron定期运行）。
Django提供了一个定制的SQL钩子，作为将手工制作的SQL注入数据库同步过程的一种方法。此自定义SQL的一个可能用途是将数据插入数据库。如果自定义SQL包含 INSERT 语句，这些插入将在每次同步数据库时执行。这包括在运行测试套件时创建的任何测试数据库的同步。
然而，在测试django 1.3的过程中，发现这个特性从未像广告中那样完全起作用。当使用不支持事务的数据库后端时，或者使用TransactionTestCase时，使用自定义SQL插入的数据在测试过程中将不可见。
不幸的是，没有办法在不引入向后不兼容的情况下纠正这个问题。Django现在强制执行由自定义SQL插入的数据将 not 测试时可见。
此更改只影响测试过程。您仍然可以使用自定义SQL将数据作为 syncdb 过程。如果您需要在测试条件期间存在数据，您应该使用 test fixtures 或使用 setUp() 测试用例的方法。
Django 1.2.4引入了一种方法 lookup_allowed 在……上面 ModelAdmin ，以处理安全问题(变更集 [15033] )。尽管这种方法从来没有被记录在案，但似乎有些人已经超越了 lookup_allowed ，尤其是为了应对由该变更集引入的倒退。虽然该方法仍未记录在案且未标记为稳定，但了解此函数的签名已更改可能会有所帮助。
12月 18, 2023