Contrôle d'accès pour plusieurs utilisateurs dans une application web

Question

Je travaille sur une application PHP + MySQL Social Networking, maintenant j'ai besoin de configurer un contrôle d'accès différent (lire, créer, éditer, supprimer) pour global (tous les articles) et/ou des éléments indépendants (élément créé par eux-mêmes) pour chaque module à grouper ou utilisateur spécifique.

Quelqu'un a-t-il des suggestions pour ce faire (structures de table, etc.)?

---

bien ici, je fournir plus de détails, j'ai actuellement un tbl_module, tbl_user et tbl_user_role. Chaque utilisateur et rôle peut avoir un accès différent à un module spécifique.

• lire
• mise à jour
• créer
• supprimer

et par un accès global Devided ou auto uniquement (compte propre ou les documents créés par eux-mêmes).

et mon approche actuelle: je crée une autre table pour contenir les détails d'accès:

• acl_uid
• mod_id (fk uid module)
• target_id (uid utilisateur fk ou uid rôle)
• acl_type (utilisateur/rôle d'identifier la référence d'identification de la cible)
• de acl_read
• acl_update
• acl_create
• acl_delete

acl_read, acl_update, acl_create, acl_delete valeur varie:

• 0 nier
• 1 permettent
• 2 se réfèrent à faible contrôle de priorité (si l'utilisateur a une valeur 2 puis se référer au rôle)
• 3 seul (e)

Je crois qu'il existe un moyen plus efficace de résoudre ce problème, ou peut-être une amélioration de mon approche actuelle.

merci pour vos réponses.

Answer 1

C'est une question assez vaste, vous n'obtiendrez probablement que des réponses très générales.

La plupart des systèmes CMS possèdent un tableau répertoriant les types de contenu pouvant être générés sur le système.

Un autre tableau décrit comment chaque type de contenu est affiché (sur la première page, sur les pages de blog individuelles, etc.).

Une autre table donne à chaque utilisateur un ou plusieurs "types d'utilisateurs" ou "groupes" tels que admin, non enregistré, modérateur, etc.

Une dernière table est une table d'accès de toutes sortes - il montre ce que chaque groupe a le pouvoir de le faire, y compris les types de contenu, il peut créer, modifier, publier, etc.

Je vous recommande de passer un peu de temps étudier les schémas de base de données d'autres logiciels CMS, tels que Slashcode, Drupal, ou l'un des autres millions de systèmes CMS.

-Adam

Answer 2

Il est en fait une question très vaste. En supposant que vous avez une séparation claire des niveaux d'application (par exemple, en utilisant MVC), alors c'est le genre de choses qui se passe dans la couche de gestion. En prenant vos besoins directs, cela pourrait être assez simple. Dans votre table d'utilisateurs, ayez un hasEdit, hasView, etc. Pour chaque élément, attachez-lui un ID utilisateur représentant le créateur. Dans la couche de gestion, la règle est qu'ils ont l'autorisation d'édition s'ils sont le créateur, ou ils ont hasEdit = true. Si vous avez un type différent et que l'autorisation hasEdit est par type, vous avez besoin d'une autre entité pour cela.

userPermission

• userPermissionId
• userId (FK)
• typeId (FK)
• hasEdit (booléen)
• hasView
• etc ..

Pour savoir s'ils ont l'autorisation de modifier, vérifiez si ils en sont propriétaires ou recherchez ce type d'éléments et l'utilisateur actuel dans la table userPermission, puis cochez la case hasEdit. Vous pouvez créer des règles supplémentaires, comme mettre un hasEdit global dans la table des utilisateurs. Ou représentant hasEdit global par une entrée dans userPermissionId avec un ID de type NULL.

Cela peut obtenir de manière plus complexe, en utilisant des rôles et un nombre variable d'autorisations .. tout se résume à vos besoins. Vous devez soigneusement préciser vos exigences d'affaires (arriver avec un tas de cas d'utilisation), et vous pouvez concevoir à partir de là. En fait, il n'y a vraiment pas assez d'informations pour arriver à ce que je viens de décrire ici (et même ce n'est probablement pas exactement ce dont vous avez besoin).

Answer 3

J'aime utiliser une sorte d'approche des règles de pare-feu ou de même une tables MySQL règles approche: vous pouvez accorder aux utilisateurs ou groupes d'utilisateurs certains droits sur certains objets ou groupes d'objets. Faites en sorte que chaque règle soit une ligne dans votre table de règles. Lorsque vous devez effectuer une action comme modifier, vous pouvez joindre à l'intérieur votre table de règles pour l'utilisateur actuel, le groupe d'utilisateurs actuel, la colonne d'édition booléenne et l'ID d'objet ou le groupe d'objets. Si vous obtenez des lignes, l'autorisation est accordée.

Answer 4

Il y a plusieurs façons de concevoir la sécurité, et j'en ai aimé pas mal pour différentes situations. Il y a UNIX-user-group-other. Il se trouve que j'aime PmWiki's security model.

J'ai développé un site web qui a utilisé la structure utilisateur-rôle-autorisations similaires à Apache. Avec ce site Web, j'ai utilisé un système de gabarit qui utilisait un fichier d'inclusion d'en-tête et un fichier d'inclusion de pied de page pour envelopper le contenu de la page avec les «trucs standard».Une page avec un contenu restreint peut définir une variable à l'autorisation requise, que le script d'en-tête recherche et, si elle est définie, appelle une fonction d'authentification qui vérifie que l'utilisateur appartient à un rôle de cette autorisation. La bonne chose à propos de l'utilisation du modèle user-role-permissions est que si la plupart de vos utilisateurs tombent dans des catégories d'autorisation bien définies, définir l'autorisation pour un utilisateur est une simple question d'ajouter le bon rôle à cet utilisateur. Les autorisations sont liées aux rôles, pas directement aux utilisateurs, ce qui vous permet de modifier facilement les autorisations de classes entières d'utilisateurs.