Est-il sûr d'accorder des autorisations "auth | User | Can change user" sans le drapeau "is staff"?

Question

J'ai besoin de certains utilisateurs pour éditer django.contrib.auth.models.User objets.

Ma première pensée a été de leur accorder la permission auth | User | Can change user et de les marquer comme is staff, afin qu'ils puissent se connecter au site Django Admin. Le problème est cependant, qu'ils peuvent utiliser cela pour se faire de super-administrateurs.

Puisque je veux qu'ils ne puissent éditer que certains champs, j'ai créé une vue très limitée pour cela. Ce qu'il me reste à faire, c'est d'accorder une permission sur cette vue à ce sous-ensemble d'utilisateurs. La seule solution que j'ai trouvée était de encore leur accorder la permission auth | User | Can change user (sans les rendre staff).

Ma question est la suivante:

Si j'utilise le @permission_required décorateur sur ce point de vue en coopération avec la auth | User | Can change user permission, est-il une autre façon pour les utilisateurs de pirater leur chemin en s'accordant le rôle super admin (même en supposant que l'utilisateur est un programmeur avancé de Django)? Je parle de choses comme e. g. Appels API que je ne connais pas, ou similaires.

Je souhaite éliminer les éventuelles erreurs dans mon code.

Answer 1

À mon humble avis, Oui, il est très sûr d'utiliser votre propre type/créer n'importe quel type de champs personnalisés sur l'utilisateur.

Dans l'un de nos projets, nous avions ajouté deux ou trois types d'utilisateurs admin et c'était assez sécurisé. Nous avions ajouté Maintainer, Administrator, SuperUser et deux types d'utilisateurs finaux (c'était l'exigence). Nous avons également fait beaucoup de personnalisation dans Django Admin pour lister tous les types de groupes et d'utilisateurs dans l'Admin Django.

JFYI nous n'avions pas fourni l'accès à Django Admin aux clients, nous avions fourni une connexion SuperUser pour créer tout type d'utilisateur pour accéder à notre outil.

Answer 2

Il peut être préférable de créer un custom permission par ex. 'can_change_user_restricted', et vérifiez cette permission dans votre vue personnalisée.

Ensuite, vous n'avez pas besoin de vous inquiéter qu'à l'avenir une autre vue/API puisse être ajoutée, ou le drapeau is_staff peut être défini, et soudainement l'utilisateur peut se faire un superutilisateur.