Примечания к выпуску 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 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 introduced a method lookup_allowed on ModelAdmin, to cope with a security issue (changeset [15033]). Although this method was never documented, it seems some people have overridden lookup_allowed, especially to cope with regressions introduced by that changeset. While the method is still undocumented and not marked as stable, it may be helpful to know that the signature of this function has changed.