Файл cookie csrf не установлен

Обновлено: 04.07.2024

При копировании кода на Linux-машины я просто заменил исходный файл исходного кода, но не удалил старые .pyc файлы, которые, как я думаю, не вызовут проблемы правильно?

Я получил одну из тех ошибок CSRF cookie not set от Django, но это не потому, что я забыл включить в свой шаблон.

Вот что я заметил:

Внутри Request Header значение cookie :

В плагине cookie, который я установил на хром, фактическое значение cookie csrf установлено на:

Внутри Request Header значение cookie :

В плагине cookie, который я установил на хром, фактическое значение cookie csrf установлено на:

Образец

Как видно из приведенных выше примеров, значение cookie внутри Request Header отличается от фактического csrfmiddlewaretoken в форме и значением фактического значения cookie.

Значение cookie текущего запроса соответствует следующему значению cookie request header's .

Чтобы помочь отладке, вот часть моего параметра settings.py:

Я использую Django 1.9.5 и python 2.7.10 .

Одно "решение"

Я столкнулся с этой проблемой до, я могу очистить все куки файлы своего браузера, и сайт будет работать правильно. Но эта проблема в конечном итоге снова появится, поэтому я действительно надеюсь, что кто-то может мне помочь (я, вероятно, просто сделал какую-то туманную ошибку).

Update

Первоначально я думал, что допустил некоторые ошибки при переопределении страницы django.contrib.auth.view , поэтому я написал свой собственный обработчик страницы входа в систему и все еще вызывает проблему.

Вот основная часть моего шаблона входа:

На машинах Linux у меня есть настройка сервера nginx как обратный прокси-сервер, который направляет запрос на порт 80 на 8001, и я запускаю сервер с помощью ./manage runserver localhost:8001 . Это единственное отличие, которое я могу представить с точки зрения настройки, В противном случае все исходный код и файл настроек идентичны.

Я начал удалять файлы cookie, но не все из них, это то, что я вижу перед их удалением:

Я удалил все файлы cookie, отличные от djdt и csrftoken , затем работала страница. Могут ли удаленные файлы cookie каким-то образом преодолеть какой-то предел, который предотвратит установку csrftoken, который находится дальше списка?

Вот значение cookie изображения выше в заголовке запроса:

Поскольку сайт работает сейчас, у меня есть пять файлов cookie вместо 14, как показано выше:

ОТВЕТЫ

Ответ 1

Вот проблема: У вас не может быть файла cookie, в котором содержится либо символ '[' или ']'

Я нашел решение после @Todor ссылка, затем я узнал об этом SO post. В основном была ошибка в python 2.7.x, которая не анализирует файлы cookie с ']' в значении. Исправлена ошибка в 2.7.10.

Я подумал, что было бы хорошо подтвердить эту проблему. Поэтому я выкопал все файлы cookie и нашел один со следующим ключом/значением:

Итак, я ввел следующий файл cookie локально и отправил на сервер:

Работала страница входа, что означает, что 2.7.10 действительно исправил ошибку.

Но потом я понял, что квадратные скобки на самом деле находятся в имени ключа не в значении, поэтому я сделал следующие тесты:

Оба файла cookie прерывают процесс входа в систему и отображают django:

Я хотел бы поблагодарить всех, кто оставил комментарий в OP: @raphv, @trinchet, @Phillip, @YPCrumble, @PeterBrittain и @Todor. Спасибо вам, ребята, за отладку со мной!

Обновление: 20 июля 2016 г.

Эта ошибка исправлена в Django 1.10, просто нужно дождаться выпуска

Обновление: 19 июля 2016 г.

Im застрял, я уже очистил cookie, использовал другой браузер, но все равно CSRF cookie не установлен.

Это также может произойти, если CSRF_COOKIE_SECURE = True установлен, и вы получаете доступ к сайту небезопасно.

вы можете включить токен сеанса, передав опцию credentials: 'include' принести:

С этой Вы можете решить его, добавив ensure_csrf_cookie оформителя на ваш взгляд

если этот метод не работает. вы попытаетесь прокомментировать csrf в промежуточном по. и снова проверить.

эта проблема возникла снова недавно из-за ошибки в самом Python.

среди затронутых версий были 2.7.8 и 2.7.9. Файл cookie не был прочитан правильно, если одно из значений содержало [ символ.

обновление Python (2.7.10) устраняет проблему.

раньше я использовал Django 1.10.Поэтому я столкнулся с этой проблемой. Теперь я понизил его до Django 1.9, и он работает нормально.

Я столкнулся с аналогичной ситуацией во время работы с DRF, решение было добавлено .метод as_view() для представления в urls.py

попробуйте проверить, установлены ли ваши settings.py

в шаблоне данные форматируются с помощью csrf_token:

проблема, кажется, что вы не обращение GET запрашивает соответствующую или прямую публикацию данных без предварительного получения формы.

позже, пользователь заполняет форму и отправляет POST запрос с данными форм.

ваш взгляд должен быть:

убедитесь, что файлы cookie chrome установлены по умолчанию для веб-сайтов. Разрешить установку локальных данных (рекомендуется).

убедитесь, что ваш сервер сеанса django настроен правильно в settings.py - . Тогда попробуйте это,

добавьте это промежуточное ПО в settings.py под MIDDLEWARE_CLASSES или MIDDLEWARE в зависимости от версии django

get_token-возвращает токен CSRF, необходимый для формы POST. Маркер является буквенно-цифровым значением. Новый токен создается, если он еще не установлен.

У меня была такая же ошибка, в моем случае добавление method_decorator помогает:

Я только однажды встретил решение очистить куки. И может быть изменен при отладке SECRET_KEY связанных.

Кто-то сталкивался с таким ответом при колбеке с LiqPay?
Обрабатываю через:

Насколько я понимаю, ответ приходит без csrf_token (откуда же ему там взятся). Ну раз так, я ставлю декоратор @csrf_exempt. Но почему декоратор не срабатывает и появляется ошибка?
p.s. Ставил CSRF_COOKIE_SECURE = True - не помогло. django.middleware.csrf.CsrfViewMiddleware установлен.

Вопрос задан более трёх лет назад
1081 просмотр

Вроде бы всё по инструкции:
раз
два
Но я бы попробовал еще с конечной функцией поиграться.
Спасибо, но все эти способы пробовал ранее, ошибка та же (

Ну мистика же! Django 2.0.4

Такой код работает. Дальше надо менять его постепенно на то, что в примере и смотреть, на каком изменении перестает работать.

Не помогло (
Частичное решение проблемы оказалось неожыданым. Вынес в основные ответы.

Не пойму, что к чему, но решение нашел в следующем:

Перенес урл и вюшку в другой апп и все заработало.
Почему то в первоначальном аппе не срабатывал декоратор csrf_exempt.
Если кто знает почему так произошло - поделитесь.

Обидно, что потратил на это день.

Добавил решение вашего вопроса. Правда, почему не срабатывает решение из коробки, я так и не выяснил.

Так же, как и автор вопроса, столкнулся с данной проблемой, при реализации веб-хуков для чат-ботов.

Перенаправление на другое приложение django у меня работало изначально.
Но, при написании универсального приложения, это не выход.

Изучил исходники django. Судя по всему, каким то образом CsrfViewMiddleware не видит у коллбека (view) поля csrf_exempt, которое и добавляется одноименным декоратором.
../django/middleware/csrf.py:212 (django 2.2)

Соответственно выходом будет добавить данное поле самостоятельно в результирующую view-функцию:

Я застрял, я уже очистил файл cookie, использовал другой браузер, но все еще не установил файл cookie csrf.

У меня очень странная проблема - CSRF cookie не установлен на некоторых клиентских браузерах. Что это может быть потенциально? Все необходимое промежуточное программное обеспечение включено, и, как я уже сказал выше, проблема появляется только на очень небольшом количестве машин, хотя там хорошо.

Вы можете включить маркер сеанса, передав опцию credentials: 'include' для извлечения:

Из этого вы можете решить эту проблему, добавив декоратор ensure_csrf_cookie в свой вид

если этот метод не сработает. вы попытаетесь прокомментировать csrf в промежуточном программном обеспечении. и проверьте еще раз.

Если вы используете DRF, проверьте правильность ваших url-шаблонов, возможно, вы забыли .as_view() :

Так вот как выглядел мой код:

И так оно и должно быть:

Я столкнулся с аналогичной ситуацией во время работы с DRF, решение заключалось в добавлении метода .as_view() к представлению в urls.py

попробуйте проверить, установлены ли вы в settings.py

В шаблоне данные форматируются с помощью csrf_token:

У меня есть некоторые проблемы в течение некоторого времени, я испытываю CSRF Cookie не установлен. Пожалуйста, посмотрите на коды ниже views.py from django.shortcuts import render_to_response from django.contrib.auth import authenticate, login from django.conf.urls import patterns, url, include.

Эта проблема снова возникла недавно из-за ошибки в самом Python.

Среди затронутых версий были 2.7.8 и 2.7.9. Файл cookie не считывался правильно, если одно из значений содержало символ [ .

Обновление Python (2.7.10) устраняет проблему.

Это также происходит, когда вы не задаете действие формы.
Для меня это показывало эту ошибку, когда код был:

Когда я исправил свой код в этом:

моя ошибка исчезла.

Проблема, по-видимому, заключается в том, что вы не обрабатываете запросы GET должным образом или непосредственно публикуете данные без предварительного получения формы.

Позже пользователь заполняет форму и отправляет запрос POST с данными формы.

Ваш взгляд должен быть:

Убедитесь, что файлы cookie chrome установлены по умолчанию для веб-сайтов. Разрешить установку локальных данных (рекомендуется).

Потому что метод render_to_response может вызвать некоторые проблемы с файлами cookie ответа.

Я только один раз встречался, решение состоит в том, чтобы очистить печенье. И может быть изменен во время отладки, связанной с SECRET_KEY.

Я использовал Django 1.10 before.So Я столкнулся с этой проблемой. Теперь я понизил его до Django 1.9, и он работает нормально.

Убедитесь, что серверная часть сеанса django правильно настроена в settings.py. Тогда попробуйте это,

Добавьте это промежуточное программное обеспечение в settings.py под MIDDLEWARE_CLASSES или MIDDLEWARE в зависимости от версии django

get_token - Возвращает токен CSRF, необходимый для формы POST. Токен представляет собой буквенно-цифровое значение. Новый токен создается, если он еще не установлен.

У меня была та же ошибка, в моем случае добавление method_decorator помогает:

На ваш взгляд, используете ли вы декоратор csrf??

from django.views.decorators.csrf import csrf_protect

@csrf_protect def view(request, params): .

Как пользоваться ¶

Чтобы воспользоваться преимуществами защиты CSRF в представлениях, сделайте следующее:

По умолчанию промежуточное ПО CSRF включено в настройках MIDDLEWARE . Если вы переопределите этот параметр, помните, что это 'django.middleware.csrf.CsrfViewMiddleware' должно происходить до того, как промежуточное ПО, которое полагается на CSRF-атаки, уже было отражено.

Если вы отключите его, что не рекомендуется, вы можете использовать его csrf_protect() в некоторых представлениях, которые хотите защитить (см. Ниже).

В любом шаблоне, который использует форму POST, используйте тег шаблона csrf_token внутри тега HTML, <form> если форма ссылается на внутренний URL-адрес, например:

С другой стороны, этого не следует делать для форм POST, нацеленных на внешние URL-адреса, поскольку это приведет к раскрытию токена CSRF и, таким образом, приведет к уязвимости.

В соответствующих функциях просмотра проверьте, что RequestContext используется для создания ответа, чтобы он работал правильно. Если вы используете функцию , общие представления или дополнительные приложения, не нужно беспокоиться, потому что все эти представления используют . render() RequestContext

Рекомендуемым источником для токена является файл cookie csrftoken , который будет присутствовать, если у вас включена защита CSRF для вашего представления, как показано выше.

Файл cookie CSRF имеет имя csrftoken по умолчанию, но вы можете изменить это имя в настройках CSRF_COOKIE_NAME .

Получить токен можно так:

Приведенный выше код можно упростить, заменив библиотеку Cookie JavaScript getCookie :

Маркер CSRF также присутствует в DOM, но только если он явно включен с помощью тега csrf_token в шаблоне. Файл cookie будет содержать стандартный токен; он CsrfViewMiddleware предпочтет cookie токену DOM. В любом случае вы гарантированно получите cookie, если токен присутствует в DOM, поэтому лучше использовать cookie!

Если представление не использует шаблон, содержащий тег csrf_token , Django может не установить файл cookie CSRF. Такая ситуация часто возникает в случаях, когда формы динамически добавляются на страницу. Чтобы решить эту проблему, Django предоставляет вид декоратора , который заставляет использовать куки: ensure_csrf_cookie() .

Установка токена для запроса AJAX ¶

Наконец, вам нужно установить заголовок для вашего запроса AJAX. Используя API fetch () :

Использование CSRF в шаблонах Jinja2 ¶

Jinja2 Механизм шаблонов Django добавляет контекст всех шаблонов, что эквивалентно языку шаблонов Django. Например : >

Метод декоратора ¶

Вместо того, чтобы добавлять CsrfViewMiddleware в качестве общей защиты, вы можете использовать декоратор csrf_protect , который предлагает точно такую же функциональность, для конкретных представлений, которые нуждаются в защите. Этот декоратор следует использовать как в представлениях, которые включают в себя токен CSRF, так и в представлениях, которые принимают данные формы POST. (Часто это одна и та же функция просмотра, но не всегда).

Не рекомендуется прибегать к использованию одного декоратора , потому что, если вы забудете его использовать, у вас будет дыра в безопасности. Стратегия «пояс и подтяжки» с использованием того и другого хороша и приведет лишь к минимальной перегрузке.

Декоратор, обеспечивающий защиту представления, подобную промежуточному программному обеспечению CsrfViewMiddleware .

Если вы используете представления на основе классов, вы можете обратиться к разделу «Украшение представлений на основе классов» .

Отклоненные запросы ¶

По умолчанию пользователю возвращается ответ «403 Forbidden», если входящий запрос не удовлетворяет проверкам, выполненным пользователем CsrfViewMiddleware . Как правило, это должно появляться только в том случае, если это настоящая атака «Подделка межсайтового запроса» или когда из-за ошибки программирования токен CSRF не был включен в форму. типа POST.

Однако страница с ошибкой не очень приятная, поэтому вы можете предоставить собственное представление для решения этой проблемы. Для этого определите настройку CSRF_FAILURE_VIEW .

Сбои CSRF регистрируются как предупреждения в журнале django.security.csrf .

Операция ¶

Защита CSRF основана на следующем:

Файл cookie CSRF, основанный на случайном секретном значении, к которому другие сайты не будут иметь доступа.

Этот файл cookie создается промежуточным программным обеспечением CsrfViewMiddleware . Он отправляется с каждым вызванным ответом django.middleware.csrf.get_token() (функция, используемая внутри для получения токена CSRF), если он еще не был определен для запроса.

Для защиты от атак BREACH токен - это не просто секрет; к секрету добавляется случайная маска, которая используется для его шифрования.

По соображениям безопасности секретное значение изменяется каждый раз, когда пользователь входит в систему.

Скрытое поле формы с именем «csrfmiddlewaretoken» присутствует во всех исходящих формах POST. Значение этого поля, опять же, является значением секрета с маской, которая добавляется к нему и используется для его шифрования. Маска регенерируется при каждом вызове, get_token() поэтому значение поля формы изменяется в каждом таком ответе.

Это действие выполняется тегом шаблона.

При проверке значения поля csrfmiddlewaretoken только секретное значение, а не полный токен, сравнивается с секретным значением содержимого cookie. Это позволяет использовать постоянно меняющиеся токены. Хотя каждый запрос может использовать свой токен, секретное значение остается общим для всех.

Эта проверка выполняется промежуточным программным обеспечением CsrfViewMiddleware .

Расширение принятых рефереров за пределы текущего хоста или домена cookie можно выполнить с помощью этой настройки CSRF_TRUSTED_ORIGINS .

Это гарантирует, что для возврата данных с запросом POST можно использовать только формы, исходящие из доверенных доменов.

Удаление заголовка Referer

Чтобы избежать раскрытия URL-адреса реферера сторонним сайтам, может быть желательно отключить реферер в тегах <a> вашего сайта. Например, можно использовать тег или включить заголовок . Из-за строгого контроля реферера в защите CSRF для запросов HTTPS эти методы приводят к сбоям CSRF для «небезопасных» запросов методов. Лучше использовать альтернативы, такие как ссылки на сторонние сайты. <meta name="referrer" content="no-referrer"> Referrer-Policy: no-referrer <a rel="noreferrer" . >"

Кеширование ¶

Если тег шаблона csrf_token используется шаблоном (или функция get_token вызывается другим способом), промежуточное ПО CsrfViewMiddleware добавляет в ответ файл cookie и заголовок . Это означает, что промежуточное ПО будет хорошо работать с промежуточным ПО кеширования, если оно используется в соответствии с инструкциями ( должно быть помещено в настройки перед любым другим промежуточным ПО). Vary: Cookie UpdateCacheMiddleware

Однако, если вы используете декораторы кеша для отдельных представлений, промежуточное ПО CSRF еще не сможет установить заголовок Vary или файл cookie CSRF, и ответ будет кэшироваться без них. Другой. В этом случае в представлениях, которые требуют вставки токена CSRF, вы должны django.views.decorators.csrf.csrf_protect() сначала использовать декоратор функции :

Тесты ¶

Ограничения ¶

Поддомены сайта могут размещать файлы cookie на клиенте для всего домена. Установив файл cookie и используя соответствующий токен, поддомены смогут обойти защиту CSRF. Единственный способ избежать этого - убедиться, что поддомены контролируются доверенными пользователями (или, по крайней мере, не могут устанавливать файлы cookie). Обратите внимание, что даже без CSRF существуют другие уязвимости, такие как фиксация сеанса, из-за которых выдача субдоменов ненадежным третьим сторонам является плохой идеей; эти уязвимости не могут быть легко устранены с помощью текущих браузеров.

Особые случаи ¶

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

Утилиты ¶

Приведенные ниже примеры относятся к представлениям на основе функций. Если вы используете представления на основе классов, вы можете обратиться к разделу «Украшение представлений на основе классов» .

Этот декоратор отмечает представление как освобожденное от защиты, обеспечиваемой промежуточным программным обеспечением. Пример:

Обычно тег шаблона csrf_token не работает, если не CsrfViewMiddleware.process_view использовался аналогичный аналог csrf_protect . Декоратор представления requires_csrf_token можно использовать, чтобы убедиться, что тег шаблона работает. Этот декоратор работает аналогично csrf_protect , но никогда не отклоняет входящий запрос.

Этот декоратор заставляет представление отправлять файл cookie CSRF.

Сценарии ¶

Для некоторых представлений необходимо отключить защиту CSRF ¶

Большинство представлений требуют защиты CSRF, но некоторые нет.

Обходной путь: вместо отключения промежуточного программного обеспечения и применения csrf_protect ко всем представлениям, которые в нем нуждаются, включите промежуточное программное обеспечение и используйте его csrf_exempt() .

CsrfViewMiddleware.process_view не используется ¶

Бывают случаи, когда он CsrfViewMiddleware.process_view не будет выполнен до вашего просмотра - например, обработчики ошибок 404 и 500 - но вам все равно нужен токен CSRF в форме.

Незащищенное представление требует токена CSRF ¶

Некоторые представления могут не быть защищены, возможно, исключены csrf_exempt , но все же должны включать токен CSRF.

Решение: используйте с csrf_exempt() последующим requires_csrf_token() (т.е. requires_csrf_token должен быть самым внутренним декоратором).

Вид нуждается в защите для определенного пути ¶

Вид нуждается в защите CSRF только при соблюдении определенного количества условий и не должен защищаться в остальное время.

Обходной путь : используйте csrf_exempt() для всей функции просмотра и, в csrf_protect() частности, для пути, который необходимо защитить. Пример:

Решение: используйте ensure_csrf_cookie() в представлении, которое отправляет страницу.

Встроенные и многоразовые приложения ¶

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

Настройки ¶

Для управления поведением Django против CSRF можно использовать ряд настроек:

Часто задаваемые вопросы ¶

Является ли отправка пары произвольных токенов CSRF (данные cookie и POST) уязвимостью? ¶

Некоторые инструменты аудита безопасности сообщают об этом как о проблеме, но, как упоминалось выше, злоумышленник не может украсть файл cookie CSRF из браузера пользователя. Возможность «украсть» или изменить собственный токен с помощью Firebug, инструментов разработчика Chrome и т. Д. не означает, что это уязвимость.

Проблематично ли, что защита Django CSRF по умолчанию не привязана к сеансу? ¶

Нет, сознательно нет. Отсутствие привязки защиты CSRF к сеансу позволяет использовать защиту на таких сайтах, как pastebin, которые разрешают отправку данных анонимным пользователям, у которых нет сеанса.

Если вы хотите сохранить токен CSRF в сеансе пользователя, установите параметр CSRF_USE_SESSIONS .

Почему после входа в систему пользователь может получить ошибку проверки CSRF? ¶

Читайте также: