Je développe une application web Django avec une suite d'outils de conception en acier pour les ingénieurs en structures. Il y aura une table de base de données d'entrées pour chaque outil de conception, et chaque rangée de chaque table correspondra à une condition de conception particulière à «résoudre». Les utilisateurs peuvent travailler uniquement ou en groupe. Chaque utilisateur doit avoir un accès continu à son propre travail afin que les conceptions puissent être affinées, copiées et adaptées, et que les rapports puissent être créés chaque fois que possible, généralement à la fin d'un projet lorsque la documentation papier sera nécessaire. Le contenu de la base de données doit alors être disponible sur un nombre quelconque de sessions se déroulant sur des périodes mesurées en mois ou même en années pour un projet de conception donné. Lorsqu'il y a un groupe d'utilisateurs, généralement tous associés à un bureau d'études donné, il sera probablement acceptable qu'ils aient tous un accès mutuel et mutuel au travail de l'autre. L'application prend en charge les activités de production d'ingénierie de routine, pas de travail de propriété intellectuelle innovante, et la vie privée en interne n'est pas la norme dans l'industrie de toute façon. Cependant, le travail doit absolument être à l'abri des regards indiscrets à l'extérieur du groupe. Idéalement, chaque groupe aurait un ou plusieurs super-utilisateurs autorisés à surveiller les membres du groupe. Probablement l'outil principal dont ils auraient besoin serait la possibilité de retirer un membre du groupe, en supprimant ses privilèges d'accès. Ce serait un super-utilisateur de groupe d'utilisateurs et ne serait pas le même qu'un super-utilisateur du côté du site.Authentification Django avec contrôle d'accès à granularité fine
Pour un accès pratique, chaque ligne de chaque table de base de données sera associée à une paire numéro de projet/nom de projet qui sera unique pour une entreprise donnée déployant un utilisateur ou un groupe d'utilisateurs. Une entreprise différente pourrait facilement choisir d'utiliser un numéro de projet en double, et même choisir un nom de projet en double, donc discriminer exactement quelles lignes de base de données appartiennent à un utilisateur donné (ou un groupe) devra probablement être suivi dans une liste "table pour chaque utilisateur (ou groupe). On espère (éventuellement) que plusieurs centaines d'utilisateurs (ou groupes d'utilisateurs) associés à des entreprises différentes (et souvent concurrentes) résoudront des dizaines de milliers de conditions de conception pour des milliers de projets utilisant ces outils.
Alors, voici mes questions:
d'abord, est-il utile d'essayer de récupérer quoi que ce soit à partir du code Django contrib.auth? Comme je le perçois, contrib.auth est conçu pour l'authentification et le contrôle d'accès qui conviennent à la blogosphère et au journalisme Web, mais cela ne permet pas un contrôle précis de l'accès au «contenu». Deuxièmement, y a-t-il un modèle disponible, un modèle, un exemple, une stratégie ou un conseil de conception que je pourrais appliquer à ce problème?
Ce projet semble impressionnant. Et vous devez le faire à Django. comment cela s'est passé? –
Je me suis débrouillé aussi. Votre 3ème paragraphe est le problème: quelle que soit votre définition d'un projet, vous devez générer une clé pour que vous puissiez y associer des données. Ne comptez jamais sur l'apport humain pour cela. Un bon test pour cela est que les entrées (par exemple le nom du projet) doivent être modifiables à tout moment. Ensuite, vous venez de dire que ce groupe (id = 12345abc) a ces groupes assignés, et ces groupes ont ces utilisateurs. Laissez uniquement les utilisateurs avec cette chaîne d'autorisations voir les données du projet. –