Django-rest-framework: La page d'administration des jetons divulgue les jetons d'accès dans les fichiers journaux

D'ACCORD. Ouais. Pas idéal.

La réponse aux questions liées aux jetons a traditionnellement été que l'implémentation fournie est délibérément (trop) simple et que vous devriez utiliser une implémentation personnalisée si vous avez besoin de quelque chose de plus complexe/meilleur. (L'essentiel ici est que nous avons évité d'ajouter plus de complexité ici pour maintenir le fardeau de maintenance raisonnable.)

Les autorisations d'accès pour les utilisateurs ayant accès à la page d'administration (élevé) et ceux ayant des autorisations pour afficher les journaux (moyen) sont différentes.

Je pense que ce n'est pas vrai pour les personnes qui utiliseraient/devraient utiliser l'implémentation fournie en production.
(Dans ces cas, ils seraient une seule et même personne.)

Je ne sais pas ce que les autres pourraient dire...

La réponse aux questions liées aux jetons a traditionnellement été que l'implémentation fournie est délibérément (trop) simple et que vous devriez utiliser une implémentation personnalisée si vous avez besoin de quelque chose de plus complexe/meilleur.

J'obtiens cette position, mais la documentation devrait alors fortement recommander aux utilisateurs de s'éloigner au minimum de l'implémentation intégrée et de la déconseiller à l'extrême. La recommandation tierce pour l'authentification par jeton/signature est https://github.com/etoccalino/django-rest-framework-httpsignature qui n'a pas été mise à jour depuis 3 ans. J'imagine qu'il y aurait beaucoup plus d'intérêt pour les fournisseurs de jetons tiers s'il n'y en avait pas un prêt à l'emploi.

Il s'agit d'une divulgation d'informations assez sérieuse IMO, donc je ne suis pas sûr que la position par défaut pour authtoken soit la bonne façon de procéder dans ce cas.

Non. C'est pourquoi je ne l'ai pas fermé...

Désolé si ma réponse a été plus brutale que prévu, ce n'était pas mon objectif.

Pas de problème! 😃

(Je me demande si nous pourrions simplement mung le ModelAdmin pour utiliser un hachage de la clé dans l'url ...)

Sournois, mais cette idée semble dangereuse aussi, même si je ne peux pas dire pourquoi.

Une migration devrait être en mesure de gérer le travail. Le plus délicat serait les clés étrangères dans d'autres tables, mais cela semble peu probable. DRF ne crée pas de FK pour les jetons, et je ne vois pas beaucoup de raisons pour lesquelles les utilisateurs le feraient non plus.

Je ne pense pas avoir déjà essayé de migrer les champs de clé primaire, mais il me semble me souvenir qu'il y a une opération qui le gère, ainsi que les mises à jour de clé étrangère correspondantes.

Ouais. Il faudrait une migration de données, mais sinon, je suppose qu'il est assez facile de basculer.

Les demandes d'extraction sont les bienvenues. Merci pour le rapport !

Le jeton doit-il nécessairement être unique ?

Je comprends le problème, mais vous devez considérer qu'en fonction de la migration que vous créez (pour résoudre ce problème), vous pouvez causer de nombreux autres problèmes (par exemple, l'introduction d'un nouveau champ PK cassera très probablement d'autres packages qui reposent sur le comportement actuel ).

Je me demande s'il est possible d'ajouter un champ entier à incrémentation automatique sur la table des jetons qui est utilisé comme référence dans la page d'administration de Django pour le jeton d'authentification, mais pas comme clé primaire de la table ?

Pour votre information, je viens de vérifier que j'ai également le même problème avec mon implémentation de jeton étendu (voir django-rest-multitokenauth ) - alors merci d'avoir signalé cette erreur dans le panneau d'administration ! J'ai hâte de voir la solution ici, afin que je puisse adapter mon package python.

Pour votre information, voici comment je l'ai corrigé dans mon package MultiTokenAuth :
https://github.com/anx-ckreuzberger/django-rest-multiauthtoken/commit/7e11ed606271eff0693a9280f8a30349c7e90b27

Je suppose que le même correctif pourrait être appliqué ici, avec la mise en garde de casser potentiellement le code d'autres personnes s'ils ont une clé étrangère vers la table de jetons

Bonjour,

Je parcourais juste les problèmes liés à l'authentification avant d'évaluer cette bibliothèque pour un projet à venir. J'ai une question simple, j'apprécierais toute aide.

Ce problème peut-il être évité simplement en n'enregistrant pas le modèle de jeton dans l'administration ?

@raunaqss Oui, vous n'avez pas besoin de l'enregistrer.

Merci d'avoir ressuscité cela.

Savons-nous dans quelle direction nous allons avec cela ?
Faut-il hacher l'url ou migrer le pk ?

Je peux faire un PR.

Une migration sera très probablement l'approche sensée ici.
Je suis assez méfiant quant à l'inclusion d'une migration dans la version 3.11, car par exemple. cela pourrait être problématique/inattendu pour les personnes ayant de très grandes tables de clés API.
Je pense qu'une chose sensée à faire sera probablement de commencer par publier une migration vers ceci séparément, afin que nous puissions nous assurer que certaines personnes sont en mesure de tout tester d'abord indépendamment de nos versions.
Une fois que nous sommes satisfaits de tout cela, nous pouvons envisager d'inclure directement la migration.

Voyons comment publier une migration pour cela séparément, plutôt que de la pousser dans la version 3.11 elle-même. Je me méfie trop des implications pour les utilisateurs avec de très grandes tables de clés API pour pousser une migration sur tous nos utilisateurs dans une version majeure.

Ce problème est ouvert depuis longtemps et, bien qu'il semble que l' observation de @jarshwah soit résolue par django-rest-knox , nous souhaitons probablement être plus sécurisés par défaut. Même si l'intention de drf est que TokenAuthentication soit simple, de nombreux développeurs sont tenus d'implémenter un mécanisme d'authentification non sécurisé. Je ne suis pas sûr que le code qui fuit du matériel secret par conception devrait être inclus hors de la boîte.

Des progrès ont-ils été réalisés dans la résolution de ce problème ? Quelqu'un est-il prêt à accepter une prime sur la question ? Je serais intéressé à contribuer au code ou à payer une prime si c'est le cas.

Je vais le privilégier pour la 3.12.

Je serais intéressé à contribuer au code

Très bienvenu pour émettre un PR pour cela, bien sûr.

Je serais intéressé à contribuer au code ou à payer une prime si c'est le cas.

Devenir sponsor est un bon moyen de contribuer. Les sponsors bénéficient d'une assistance prioritaire et peuvent signaler un problème si nécessaire. https://fund.django-rest-framework.org/topics/funding/#corporate-plans

Tout cela sonne bien ! Je suis maintenant un sponsor de drf et encode. Je ne manquerai pas de mettre à jour ce problème si/quand je commencerai à travailler sur une résolution.

Fantastique, merci beaucoup. 🙏

D'accord, donc ce n'est vraiment pas évident de savoir comment aborder cela avec élégance.

Nous aimerions vraiment que le modèle utilise simplement un int à incrémentation automatique pour la clé primaire et que le champ "clé" soit un champ standard unique et indexé, mais nous ne pouvons pas migrer vers cela. Quelles sont nos options...

• Nous pourrions introduire quelque chose comme rest_framework.authtoken2 et faire en sorte que la documentation s'y réfère à la place, afin que les nouveaux projets obtiennent un meilleur ensemble de valeurs par défaut.
• Nous pourrions continuer à utiliser le champ existant comme PK et ajouter un nouveau champ pour la valeur réelle du jeton. Il n'est pas clair si nous pourrions introduire une migration de données en copiant les valeurs, comme cela pourrait être le cas ? être problématique pour les utilisateurs disposant de grands ensembles de données existants. Cela semble décent ... https://stackoverflow.com/questions/41500811/copy-a-database-column-into-another-in-django Nous devons également faire très attention au comportement toujours correct pour les bases de code non migrées. Si nous travaillions sur une application déployée, nous voudrions normalement commencer par introduire le nouveau champ et nous assurer que nous écrivons les mêmes valeurs dans les deux champs tout en laissant la base de code se référer à l'ancien champ pendant un certain temps. Et seulement une fois que tout est déployé et synchronisé, introduisez le changement de code en passant à l'utilisation du nouveau champ.
• Nous pourrions continuer comme nous sommes mais introduisons quelques changements d'administration.

Quelqu'un a-t-il des idées préliminaires à ce sujet?

Aussi: C'est pourquoi celui-ci est en attente depuis si longtemps - il n'y a pas de réponse facile. 😬

J'ai ouvert #7341 en regardant l'option _"introduire quelques modifications d'administration"_.