Django-rest-framework: Die Token-Verwaltungsseite gibt Zugriffstokens in Protokolldateien weiter

OK. Ja. Nicht ideal.

Die Antwort auf tokenbezogene Fragen war traditionell, dass die bereitgestellte Implementierung absichtlich (zu) einfach ist und dass Sie eine benutzerdefinierte Implementierung verwenden sollten, wenn Sie etwas Komplexeres/Besseres benötigen. (Unterm Strich haben wir uns davon abgehalten, hier noch mehr Komplexität hinzuzufügen, um den Wartungsaufwand angemessen zu halten.)

Die Zugriffsberechtigungen für Benutzer mit Zugriff auf die Admin-Seite (hoch) und Benutzer mit Berechtigungen zum Anzeigen von Protokollen (mittel) sind unterschiedlich.

Ich denke, das gilt nicht für Leute, die die mitgelieferte Implementierung in der Produktion verwenden würden / sollten.
(In diesen Fällen wäre es ein und dieselbe Person.)

Ich bin mir nicht sicher, was andere sagen könnten ...

Die Antwort auf tokenbezogene Fragen war traditionell, dass die bereitgestellte Implementierung absichtlich (zu) einfach ist und dass Sie eine benutzerdefinierte Implementierung verwenden sollten, wenn Sie etwas Komplexeres/Besseres benötigen.

Ich verstehe diese Position, aber dann sollten die Dokumente den Benutzern dringend empfehlen, sich zumindest von der integrierten Implementierung zu entfernen und am äußersten Ende der Dinge abzulehnen. Die Empfehlung eines Drittanbieters für Token/Signatur-Authentifizierung lautet https://github.com/etoccalino/django-rest-framework-httpsignature , die seit 3 ​​Jahren nicht mehr aktualisiert wurde. Ich könnte mir vorstellen, dass es viel mehr Interesse an Token-Anbietern von Drittanbietern geben würde, wenn einer nicht sofort einsatzbereit wäre.

Dies ist meiner Meinung nach eine ziemlich ernsthafte Offenlegung von Informationen, daher bin ich mir nicht sicher, ob die Standardposition für authtoken in diesem Fall der richtige Weg ist.

Nein. Deshalb habe ich es nicht geschlossen...

Tut mir leid, wenn meine Antwort rauer rüberkam als beabsichtigt, das war nicht mein Ziel.

Keine Probleme! 😃

(Ich frage mich, ob wir ModelAdmin einfach mung könnten, um einen Hash des Schlüssels in der URL zu verwenden ...)

Hinterhältig, aber diese Idee fühlt sich auch gefährlich an, obwohl ich nicht sagen kann, warum.

Eine Migration sollte in der Lage sein, den Job zu bewältigen. Das Knifflige wären Fremdschlüssel in anderen Tabellen, aber das scheint unwahrscheinlich. DRF erstellt keine FKs für Tokens, und ich sehe auch nicht viele Gründe, warum Benutzer dies tun würden.

Ich glaube nicht, dass ich zuvor versucht habe, Primärschlüsselfelder zu migrieren, aber ich erinnere mich, dass es eine Operation gibt, die damit umgeht, und auch die entsprechenden Fremdschlüsselaktualisierungen.

Jep. Es würde eine Datenmigration erfordern, aber ansonsten denke ich, dass es einfach genug ist, umzuschalten.

Pull-Requests willkommen. Danke für den Bericht!

Muss das Token unbedingt eindeutig sein?

Ich verstehe das Problem, aber Sie sollten bedenken, dass Sie je nachdem, welche Migration Sie erstellen (um dieses Problem zu lösen), viele andere Probleme verursachen können (z. B. wird die Einführung eines neuen PK-Felds höchstwahrscheinlich einige andere Pakete beschädigen, die auf dem aktuellen Verhalten beruhen ).

Ich frage mich, ob es möglich ist, der Token-Tabelle ein Auto-Increment-Integer-Feld hinzuzufügen, das als Referenz auf der Django-Admin-Seite für das Auth-Token verwendet wird, aber nicht als Primärschlüssel der Tabelle?

Zu Ihrer Information, ich habe gerade überprüft, dass ich auch das gleiche Problem mit meiner erweiterten Token-Implementierung habe (siehe django-rest-multitokenauth ) - also danke, dass Sie auf diesen Fehler im Admin-Panel hingewiesen haben! Ich freue mich darauf, die Lösung hier zu sehen, damit ich mein Python-Paket anpassen kann.

Zu Ihrer Information, so habe ich es in meinem MultiTokenAuth-Paket behoben:
https://github.com/anx-ckreuzberger/django-rest-multiauthtoken/commit/7e11ed606271eff0693a9280f8a30349c7e90b27

Ich denke, derselbe Fix könnte hier angewendet werden, mit der Einschränkung, dass möglicherweise der Code anderer Leute gebrochen wird, wenn sie einen Fremdschlüssel für die Token-Tabelle haben

Hallo,

Ich habe nur Probleme im Zusammenhang mit der Authentifizierung durchgesehen, bevor ich diese Bibliothek für ein bevorstehendes Projekt bewertet habe. Ich habe eine einfache Frage, wäre für jede Hilfe dankbar.

Kann dieses Problem vermieden werden, indem das Token-Modell einfach nicht im Administrator registriert wird?

@raunaqss Ja, du musst es nicht registrieren.

Vielen Dank, dass Sie dies erneut angesprochen haben.

Wissen wir, in welche Richtung wir damit gehen?
Sollen wir die URL hashen oder die pk migrieren?

Ich kann eine PR machen.

Eine Migration wird hier sehr wahrscheinlich der sinnvolle Ansatz sein.
Ich bin ziemlich vorsichtig, wenn es darum geht, eine Migration in die Version 3.11 aufzunehmen, da z. Es könnte für Leute mit sehr großen API-Schlüsseltabellen problematisch/unerwartet sein.
Ich denke, eine vernünftige Sache wird wahrscheinlich sein, damit zu beginnen, eine Migration dazu separat zu veröffentlichen, damit wir sicherstellen können, dass einige Leute in der Lage sind, alles zuerst unabhängig von unseren Veröffentlichungen zu testen.
Sobald wir mit allem zufrieden sind, können wir die Migration direkt einbeziehen.

Lassen Sie uns einen Blick darauf werfen, eine Migration dafür separat zu veröffentlichen, anstatt sie in der Version 3.11 selbst zu veröffentlichen. Ich bin zu vorsichtig mit den Auswirkungen für Benutzer mit sehr großen API-Schlüsseltabellen, um eine Migration für alle unsere Benutzer in einer Hauptversion durchzuführen.

Dieses Problem ist seit langem offen, und obwohl die Beobachtung von @jarshwah anscheinend von django-rest-knox angesprochen wird, möchten wir wahrscheinlich standardmäßig sicherer sein. Auch wenn drf beabsichtigt, TokenAuthentication einfach zu gestalten, müssen viele Entwickler einen unsicheren Authentifizierungsmechanismus implementieren. Ich bin mir nicht sicher, ob Code, der geheimes Material preisgibt, standardmäßig enthalten sein sollte.

Wurden Fortschritte bei der Lösung dieses Problems erzielt? Ist jemand bereit, ein Kopfgeld in dieser Angelegenheit zu nehmen? Ich wäre daran interessiert, Code beizusteuern oder eine Prämie zu zahlen, wenn ja.

Ich werde es für 3.12 priorisieren.

Ich wäre daran interessiert, Code beizusteuern

Sehr gerne, sicher, eine PR dafür herauszugeben.

Ich wäre daran interessiert, Code beizusteuern oder eine Prämie zu zahlen, wenn ja.

Sponsor zu werden ist eine gute Möglichkeit, einen Beitrag zu leisten. Sponsoren haben vorrangigen Support und können ein Problem bei Bedarf eskalieren. https://fund.django-rest-framework.org/topics/funding/#corporate-plans

Das klingt alles super! Ich bin jetzt Sponsor von drf und encode. Ich werde dieses Problem auf jeden Fall aktualisieren, wenn/wenn ich mit der Arbeit an einer Lösung beginne.

Fantastisch, vielen Dank. 🙏

Okay, es ist wirklich nicht offensichtlich, wie man das elegant angeht.

Wir möchten wirklich, dass das Modell nur ein automatisch inkrementierendes Int für den Primärschlüssel verwendet und dass das Feld „Schlüssel“ ein standardmäßiges eindeutiges, indiziertes Feld ist, aber wir können nicht dorthin migrieren. Also, was sind unsere Möglichkeiten...

• Wir könnten so etwas wie rest_framework.authtoken2 einführen und die Dokumentation stattdessen darauf verweisen lassen, damit neue Projekte bessere Standardeinstellungen erhalten.
• Wir könnten das vorhandene Feld weiterhin als PK verwenden und ein neues Feld für den tatsächlichen Tokenwert hinzufügen. Es ist nicht klar, ob wir eine Datenmigration einführen könnten, bei der die Werte kopiert werden, wie es möglich wäre? für Benutzer mit großen vorhandenen Datensätzen problematisch sein. Das sieht anständig aus ... https://stackoverflow.com/questions/41500811/copy-a-database-column-into-another-in-django Wir müssten auch ziemlich vorsichtig sein, ob noch korrektes Verhalten für nicht migrierte Codebasen vorhanden ist. Wenn wir an einer bereitgestellten App arbeiten, möchten wir normalerweise damit beginnen, das neue Feld einzuführen und sicherzustellen, dass wir die gleichen Werte in beide Felder schreiben, während die Codebasis noch für einen bestimmten Zeitraum auf das alte Feld verweist. Und erst wenn das alles bereitgestellt und synchronisiert ist, führen Sie die Codeänderung ein, die auf die Verwendung des neuen Felds umschaltet.
• Wir könnten so weitermachen wie bisher, aber einige Admin-Änderungen einführen.

Hat jemand eine Vorüberlegung dazu?

Außerdem: Deshalb steht diese so lange an - darauf gibt es keine einfache Antwort. 😬

Ich habe #7341 geöffnet, um einen Blick auf die Option _"Einige Admin-Änderungen einführen"_ zu werfen.