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

Добро пожаловать в Django 1.2.5!

Это пятый выпуск с исправлениями ошибок в серии Django 1.2, улучшающий стабильность и производительность кодовой базы Django 1.2.

За четырьмя исключениями Django 1.2.5 поддерживает обратную совместимость с Django 1.2.4. Он также содержит ряд исправлений и других улучшений. Django 1.2.5 - это рекомендуемое обновление для любой разработки или развертывания, в настоящее время использующей или нацеленной на Django 1.2.

Полную информацию о новых функциях, обратной несовместимости и устаревших функциях в ветке 1.2 см. В примечаниях к выпуску Django 1.2 .

Обратно несовместимые изменения

Исключение 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 , особенно для того, чтобы справиться с регрессиями, внесенными этим набором изменений. Хотя метод все еще недокументирован и не отмечен как стабильный, может быть полезно знать, что сигнатура этой функции изменилась.

Copyright ©2020 All rights reserved