Une meilleure façon de décrire CRUD dans une application web?

Question

Nous avons refacturé notre application d'administration basée sur le Web (encore une fois) et nous sommes restés un peu bloqué en décrivant les permissions impliquées dans ce que nous appelions les opérations CRUD (créer-lire-mettre à jour-supprimer). Nous avons constaté que simplement essayer de décrire une action/autorisation en termes de CRUD ne s'applique pas vraiment à une application web. Il semble que CRUD en tant que concept est réparti sur la portée des données - à la fois dans la base de données et dans le modèle d'application:

Scope Permissions    Example 
----- -----------    ------- 
Table READ      I can view a list of all orders 
Row  READ | CREATE | DELETE I can view an individual product, I can create a new product and I can delete it from the database 
Field READ | UPDATE    I can view and update a customer's username 

Nous sommes aux prises pour arriver à une table d'autorisations concise sans mélanger la portée . Par exemple, si je veux créer un nouveau produit, je dois avoir accès à la table des produits, LIRE et CRÉER une ligne de produits, et avoir un accès READ et UPDATE au champ du nom du produit ... ce qui représente un total de un arbre d'autorisations très salissant! À l'heure actuelle, nous avons des méthodes stupides comme hasAccess($object, $user_ID) partout et imbriqués 'n' niveaux profonds dans les déclarations if/else pour répondre à la situation ci-dessus.

Existe-t-il d'autres moyens bien connus de décrire les autorisations utilisateur sans recourir à CRUD?

Merci pour votre aide!

(et, avant de vous demander, oui, nous avons examiné de nombreux cadres pour voir comment ils le font, et non, je ne peux pas voir mon exemple dans la documentation!)

Answer 1

vous avez décrit une couche de base de données type de modèle de sécurité - qui fonctionne bien, en particulier si vous avez un accès direct à la base de données depuis l'extérieur de votre application.

Si vous n'avez pas accès à une base de données externe, vous pouvez envisager de créer une sécurité sur vos objets métier, et non sur les objets du modèle de données. Dans votre exemple, vous créez une classe pour PRODUCT et vous donnez des autorisations comme CREATE, ce qui implique différents niveaux de privilèges réels dans la couche suivante (couche de données).

Si vous avez la possibilité de corruption de données de la part de certains administrateurs en utilisant une ligne de commande, alors peut-être vous voulez respecter les contraintes de niveau de base de données pour toujours assurer l'intégrité.