Où mettre la logique de gestion des droits dans l'architecture logicielle MVC

Question

Disons que j'ai des modèles qui sont sujets à droits lorsqu'ils sont utilisés par les utilisateurs, mais pas lorsqu'ils sont utilisés par la logique métier.

Pour exemple: Quand on crée un élément A, il crée automatiquement un élément B.

Les utilisateurs doivent avoir le droit de créer A ou B s'il veut créer un. Mais la logique métier lors de la création de B à partir de A n'a pas besoin de droits.

Si je mets le bon système dans la logique métier, je reçois des classes qui ont une forte dépendance à la session et A ne peut pas créer un B si l'utilisateur connecté n'a pas le droit. Si je mets les gestionnaires de droits dans les contrôleurs, j'ai l'impression que ma logique métier n'est pas sûre car tout programmeur pourrait oublier de tester les droits avant de créer un objet et ne serait pas arrêté, et il y a duplication de code si 2 contrôleurs sont capables mettre à jour un article pour une raison quelconque.

Où mettriez-vous la gestion des droits?

Je Coul créer l'héritage de chaque objet qui serait utilisé par les contrôleurs, et mettre en œuvre la limitation des droits, alors que la logique métier accéderait les objets eux-mêmes. Les contrôleurs créent UserA, UserB tandis que l'objet A crée directement un objet B. Mais il semble que je devrais dupliquer (hériter) tous les objets de logique métier qui doivent être utilisés dans un contrôleur, donc 80% d'entre eux.

Answer 1

Voici un exemple:

<!-- language: php --> 
//abstact Model 
abstract class Models { 
    public function save() { 
     if($this->id === null) { 
      $this->insert(); 
     } else { 
      $this->update(); 
     } 
    }  

    abstract protected function insert() { 
     //insertion in DB 
    }  

    abstract protected function update() { 
     //update in DB 
    } 
}  


//A Model 
class A extends Model { 
    protected function insert() { 
     //check if logged in user can insert A objects otherwise throw an exception 
     //insert in DB  

     $b = new B; 
     //set $b datas 
     $b->save(); 
    }  

    protected function update() { 
     //check if logged in user can update A objects and has rights on instanciated A otherwise throw an exception 
     //update in DB 
    } 
}  

//B Model 
class B extends Model { 
    protected function insert() { 
     //check if logged in user can insert B objects otherwise throw an exception 
     //insert in DB 
    }  

    protected function update() { 
     //check if logged in user can update B objects and has rights on instanciated B otherwise throw an exception 
     //update in DB 
    } 
}  

//A Controller 
class AController() { 

    public function createA() { 
     $a = new A; 
     //set $a datas 
     $a->save() 
    }  

    public function updateA($id) { 
     $a = new A($id); 
     //set new $a datas 
     $a->save() 
    } 
}  

//B Controller 
class BController() { 

    public function createB() { 
     $b = new B; 
     //set $b datas 
     $b->save() 
    }  

    public function updateB($id) { 
     $b = new B($id); 
     //set new $b datas 
     $b->save() 
    } 
} 

Si je garde les vérifications à l'intérieur des modèles, objet A ne peut pas créer un objet B si les utilisateurs ne peuvent pas, mais il faut que ce ne sont pas les utilisateurs qui créent B Cet exemple, c'est la logique métier à travers un code. Si je prends des vérifications sur des modèles pour les mettre dans les contrôleurs, je suis exposé à un programmeur qui oublie la vérification, et peut avoir beaucoup de duplication lorsque différents contrôleurs doivent mettre à jour un élément.

Jusqu'à présent, je pensais à:

• 1 droits Puting contrôles dans le contrôleur, mais il ne semble pas sûr
• 2 Injecter l'utilisateur, mais je devrais créer un « tous les droits sur » utilisateur qui serait utilisé par la logique métier
• 3 Ajout d'un choix de norights de $ sur les méthodes de sauvegarde() qui serait faux par défaut, mais défini comme vrai par la logique métier à outrepasser les contrôles des droits

Aucune de ces idées s me satisfait pleinement pour différentes raisons:

• 1 non modèles sûrs si l'on oublie les contrôles
• 2 super-utilisateur ne sonne pas très bon
• 3 sons sales

Answer 2

Je vous suggère de utiliser laravel pour le même. Laravel fournit un middleware que vous devez spécifier dans le fichier de route.donc chaque fois que l'un des contrôleurs serait appelé, le premier middleware doit être appelé et toutes les conditions seront alors vérifiées là-bas, après quoi il sera transmis au contrôleur. Dans le middleware, vous pouvez créer un fichier de classe qui vérifiera les rôles et les droits ou les permissions nécessaires.

vous pouvez consulter https://heera.it/laravel-5-1-x-acl-middleware

ou peut vous https://github.com/Zizaco/entrust#user-relation-to-roles