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-токена, что сделает недействительным тот, который находится на вашей форме.

Цитирую другого :

  1. Пользователям присваивается куки сессии, когда они попадают на страницу PHP. Токен CSRF ассоциируется с сессией, когда пользователи посещают страницу входа.
    2. .
  2. Запросы к фавикону отправлялись на PHP вместо статического ресурса. Обычно это нормально, так как PHP увидит cookie.
  3. Но поскольку запрос выглядел как запрос к статическому ресурсу, Varnish удалил куки, прежде чем передать его обратно в Apache/PHP. Это означало, что PHP создал новую сессию, которая заменила старую.

https://news.ycombinator.com/item?id=3590328

Вернуться на верх