Примечания к выпуску Django 1.2.5 ¶

Исключение CSRF для запросов AJAX ¶

Django включает механизм защиты от CSRF, который использует токен, вставленный в исходящие формы. Затем промежуточное ПО проверяет наличие токена при отправке формы и проверяет его.

До Django 1.2.5 наша защита CSRF делала исключение для запросов AJAX по следующим причинам:

• Многие наборы инструментов AJAX добавляют заголовок X-Requested-With при использовании XMLHttpRequest.
• В отношении XMLHttpRequest браузеры придерживаются строгой политики одного и того же происхождения.
• В контексте браузера единственный способ добавить настраиваемый заголовок такого рода - это XMLHttpRequest.

Поэтому для простоты использования мы не применяли проверки CSRF к запросам, которые выглядели как AJAX на основе заголовка X-Requested-With. Веб-фреймворк Ruby on Rails имел аналогичное исключение.

Недавно инженеры Google рассказали членам команды разработчиков Ruby on Rails о комбинации плагинов браузера и перенаправлений, которые могут позволить злоумышленнику предоставлять настраиваемые заголовки HTTP по запросу на любой веб-сайт. Это может позволить поддельному запросу выглядеть как запрос AJAX, тем самым побеждая защиту CSRF, которая доверяет природе запросов AJAX с одинаковым происхождением.

Майкл Козиарски из команды Rails обратил на это наше внимание, и мы смогли подготовить пробную версию, демонстрирующую ту же уязвимость в обработке CSRF в Django.

Чтобы исправить это, Django теперь будет применять полную проверку CSRF ко всем запросам, независимо от очевидного происхождения AJAX. Это технически несовместимо с предыдущими версиями, но считается, что риски безопасности перевешивают проблемы совместимости в этом случае.

Кроме того, Django теперь будет принимать токен CSRF в настраиваемом HTTP-заголовке X-CSRFTOKEN, а также в самой отправке формы для простоты использования с популярными инструментами JavaScript, которые позволяют вставлять настраиваемые заголовки во все запросы AJAX.

См. Документацию CSRF, например, код jQuery , демонстрирующий эту технику, и убедитесь, что вы просматриваете документацию для своей версии Django, поскольку точный необходимый код отличается для некоторых более старых версий Django.

FileField больше не удаляет файлы ¶

В более ранних версиях Django, когда экземпляр модели, содержащий a, FileFieldбыл удален, FileFieldон также удалял файл из внутреннего хранилища. Это открыло дверь для нескольких потенциально серьезных сценариев потери данных, включая откат транзакций и полей в разных моделях, ссылающихся на один и тот же файл. В Django 1.2.5 FileFieldникогда не удаляет файлы из внутреннего хранилища. Если вам нужно очистить потерянные файлы, вам нужно будет обработать это самостоятельно (например, с помощью специальной команды управления, которую можно запускать вручную или по расписанию, чтобы запускать периодически, например, cron).

Использование кастомного SQL для загрузки исходных данных в тесты ¶

Django предоставляет настраиваемые обработчики SQL как способ внедрить созданный вручную SQL в процесс синхронизации базы данных. Одно из возможных применений этого пользовательского SQL - вставка данных в вашу базу данных. Если ваш пользовательский SQL содержит INSERTоператоры, эти вставки будут выполняться каждый раз при синхронизации вашей базы данных. Это включает синхронизацию любых тестовых баз данных, которые создаются при запуске набора тестов.

Однако в процессе тестирования Django 1.3 было обнаружено, что эта функция никогда не работала полностью, как было заявлено. При использовании серверной части базы данных, не поддерживающей транзакции, или при использовании TransactionTestCase данные, вставленные с помощью пользовательского SQL, не будут видны в процессе тестирования.

К сожалению, не было способа исправить эту проблему без обратной несовместимости. Вместо того, чтобы оставлять введенные SQL исходные данные в неопределенном состоянии, Django теперь применяет политику, согласно которой данные, вставленные с помощью пользовательского SQL, не будут видны во время тестирования.

Это изменение влияет только на процесс тестирования. Вы по-прежнему можете использовать собственный SQL для загрузки данных в производственную базу данных как часть syncdb процесса. Если вам требуется, чтобы данные существовали в условиях тестирования, вы должны либо вставить их с помощью тестовых приспособлений , либо использовать setUp()метод вашего тестового примера.

ModelAdmin.lookup_allowed подпись изменена ¶

Джанго 1.2.4 ввел метод lookup_allowedна ModelAdmin, чтобы справиться с вопросом безопасности (ревизии [15033] ). Хотя этот метод никогда не был задокументирован, кажется, что некоторые люди его переопределили lookup_allowed, особенно для того, чтобы справиться с регрессами, внесенными этим набором изменений. Хотя метод все еще недокументирован и не отмечен как стабильный, может быть полезно знать, что сигнатура этой функции изменилась.