Примечания к выпуску 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 docs for example jQuery code, который демонстрирует эту технику, убедившись, что вы смотрите документацию для вашей версии Django, поскольку точный необходимый код отличается для некоторых старых версий Django.
FileField больше не удаляет файлы¶
В ранних версиях Django при удалении экземпляра модели, содержащего 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. Если вам требуется, чтобы данные существовали во время условий тестирования, вы должны либо вставить их с помощью test fixtures, либо с помощью метода setUp() вашего тестового случая.
Изменена подпись ModelAdmin.lookup_allowed¶
В Django 1.2.4 появился метод lookup_allowed на ModelAdmin, чтобы справиться с проблемой безопасности (набор изменений [15033]). Хотя этот метод никогда не документировался, похоже, что некоторые люди переопределили lookup_allowed, особенно для того, чтобы справиться с регрессиями, внесенными этим набором изменений. Хотя метод по-прежнему не документирован и не помечен как стабильный, может быть полезно знать, что сигнатура этой функции изменилась.