403 автор: graphene-django. не используйте csrf_exempt

Если вы хотите использовать промежуточное ПО CSRF с Graphene, вам необходимо установить токен CSRF в cookie заголовков ваших запросов.

У меня нет опыта работы с Insomnia, но я уверен, что это позволит вам настроить заголовок запроса, как это делает ссылка Apollo.

Допустим, у вас есть http://127.0.0.1:8000/graphql/ и используется JWT. Следите за этими скриншотами, может быть, они вам помогут.

Вар. 1) Установить заголовок X-CSRFToken (также можно попробовать X-CSRFTOKEN и csrftoken)

Вар. 2) Не очень правильное решение, но оно простое и работает! Используйте GET запрос вместо POST. Как-то работает ...

ИЛИ

Вар. 3) У меня не сработало Также. Вы можете попробовать пойти правильным путем и добавить в cookie X-CSRFTOKEN а) нажмите вкладку Cookie б) Кнопка "Управление файлами cookie" в) Действия -> Добавить файл cookie P.S. На самом деле Insomnia автоматически вводит csrftoken, вы можете попробовать обычный REST POST, и вы увидите, что он работает нормально, и есть csrftoken, автоматически добавляемый бессонницей ...

Я бы не рекомендовал второй метод @yestema для решения проблемы, с которой вы столкнулись.

Избегайте использования методов GET для запроса конечной точки GraphQL

Если кто-то хочет реализовать этот обходной путь и также использует Graphql для mutations, это выглядит как плохой дизайн.

В качестве стандарта было установлено, что запросы GET не должны изменять состояние сервера или базы данных, а mutations в большинстве случаев используется для изменения состояния того или другого (возможно, только базы данных, поскольку ваше приложение должно быть без гражданства).

Обратите внимание, что вы также можете использовать методы query для изменения состояния вашего бэкэнда, но, опять же, это будет противоречить установленному стандарту, как объясняется в документация по grapqhl:

[...] In REST, any request might end up causing some side-effects on the server, but by convention it's suggested that one doesn't use GET requests to modify data. GraphQL is similar - technically any query could be implemented to cause a data write. However, it's useful to establish a convention that any operations that cause writes should be sent explicitly via a mutation.

Когда безопасно использовать декоратор csrf_exempt?

Чтобы дать подсказки людям, которые задаются вопросом, насколько плохо избавляться от проверок CSRF по умолчанию, вот мое объяснение за два цента.

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

Если вы используете приложение Django только как серверную часть API, скорее всего, вы полагаетесь на другой механизм аутентификации, такой как Токен DRF или какой-то Реализация JWT.

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

tl; dr

Продолжайте отправлять запросы GraphQL с запросами POST, это лучшая практика.

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

Однако если вы используете систему аутентификации по умолчанию Django - то есть sessionid, хранящийся в cookie, затем вы должны принудительно выполнить проверку csrf. На этом этапе ваш единственный шанс, как сказано в предыдущих ответах, - добавить заголовок X-CSRFToken в ваши HTTP-запросы и передать ему значение файла cookie csrftoken, которое было автоматически установлено предыдущими запросами к серверу.

Сначала я разместил этот ответ на GitHub, но подумал, что он может быть полезен и здесь.

То, что вы ищете, это csrf_exempt в вашем url(r'^graphql', csrf_exempt(GraphQLView.as_view(graphiql=True))),

Вы можете импортировать его так: from django.views.decorators.csrf import csrf_exempt.

Токен csrf не требуется в конечной точке GraphQL, поскольку это API.

CSRF tokens are required in production by default because django doesn't know which POST request is for a form and which isn't. Also CSRF might be useful in the case you want to use the GraphQL endpoint only on your website (so having the token is an additional security measure). But for you case it is totally fine to remove the CSRF token check in production.