DJango Post csrf_token invalid и /favicon.ico not found
У меня возникла проблема с DJango. Я пытаюсь отправить данные в SQL базу данных в DJango. Поэтому мне нужен мой токен, который я получаю с помощью {{ csrf_token }}. Но когда я отправляю данные на HTML-сайт, он сообщает мне POST 403 Forbidden, а терминал DJango говорит NotFound: /favicon.ico, а также Forbidden (CSRF-токен из POST имеет неправильную длину.): /ausgeben/
Есть ли у кого-нибудь решение для этого. Ниже приведен код, который я использую для запроса токена.
Спасибо!
let formData = new FormData();
formData.append("name", name);
formData.append("gewinde", gewinde);
formData.append("laenge", laenge);
formData.append("durchmesser", durchmesser);
//formData.append("containerNR", containerNR);
formData.append('csrfmiddlewaretoken', token);
fetch('/ausgeben/',{
method: 'POST',
body: formData
});
Попробуйте отправить csrftoken
в fetch
заголовках, а не в теле запроса. Оговорюсь, что я не использовал это с fetch
, но это было необходимо с JQuery и $.ajax
запросом.
fetch('/ausgeben/',{
headers: {
'X-CSRFToken': token
},
...
TL;DR Добавьте favicon.ico
Длинная версия :
Ища другие темы о проблемах CSRF, я нашел эту.
Я думаю, что вы столкнулись со старой (но, похоже, все еще актуальной) проблемой с CSRF и некоторыми браузерами. Часто это связано с файлом favicon.ico, но может произойти и с другими статическими ресурсами (например, javacript sourcemap *.map файлы).
После доступа к вашей странице браузер запрашивает файл favicon.ico. Если файл не существует И запрос обрабатывается вашим фреймворком, это может привести к генерации нового CSRF-токена, что сделает недействительным тот, который находится на вашей форме.
Цитирую другого :
- Пользователям присваивается куки сессии, когда они попадают на страницу PHP. Токен CSRF ассоциируется с сессией, когда пользователи посещают страницу входа.
.- Запросы к фавикону отправлялись на PHP вместо статического ресурса. Обычно это нормально, так как PHP увидит cookie.
- Но поскольку запрос выглядел как запрос к статическому ресурсу, Varnish удалил куки, прежде чем передать его обратно в Apache/PHP. Это означало, что PHP создал новую сессию, которая заменила старую.