Ich habe mehrere Django-Server (API-Backend für mobile Clients) hinter einem Load Balancer ausgeführt. Aber wenn ich einige Male auf den Django Admin zugreife, bekomme ich 403 Fehler. Handelt es sich um csrf-Cookie?Django admin CSRF 403 Fehler
My Load-Balancer-Einstellung ist,
Session Stickiness - Keine
Algorithmus - Round-Robin
Ich kann jede Situation nicht Bebilderung, wenn es möglich ist, bis Sie alle Job in einem Browser-Tab tun. Wenn Sie ein Formular (mit GET-Anfrage) anfordern, generieren Sie csrf cookie (wenn es noch nicht existiert) und generieren csrfmiddlewaretoken für diesen Cookie, als Antwort erhalten Sie sowohl csrf-Token als auch Cookie-Wert im konsistenten Zustand. Bei einer POST-Anfrage sendet Ihr Browser beide und vergleicht sie auf der Serverseite. Dieses Verhalten sollte also nicht vom Backend abhängen. Aber Sie können Ihre Annahme immer mit Logger testen. Aus der Dokumentation:
CSRF-Fehler werden als Warnungen für den Logger django.security.csrf protokolliert.
in Django Changed 1.11:
In älteren Versionen CSRF Ausfälle an das django.request Logger protokolliert werden.
Das ist der springende Punkt des CSRF-Schutzes, der von einem Backend abhängt. Es vergleicht das Token aus dem Client-Cookie mit dem Referenzwert, der in einer Sitzungsvariablen in diesem spezifischen Back-End gespeichert ist. Senden Sie diese Anfrage an ein anderes Backend und es sollte fehlschlagen. – serg
Ich stimme zu, wenn Sie Django 1.11 mit 'CSRF_USE_SESSIONS = True' verwenden. In anderen Fällen, unabhängig davon, welches Backend csrfmiddlewaretoken für Sie generiert, da es nur auf den gesendeten Cookie-Wert abhängt. Natürlich nehme ich an, dass alle Backends denselben Quellcode haben. –
können Sie mir beibringen, wie Sie dies tun, bitte –
Sie müssen entweder Sitzung Stickness oder deaktivieren CSRF. – serg
Hallo, hast du das gelöst? Ich habe das gleiche Problem – psychok7