2009-10-13 6 views
2

Aux prises avec une décision sur la meilleure façon de gérer l'authentification au niveau du client avec la hiérarchie de modèle suivant:CakePHP: autorisations basées sur un modèle?

client -> Store -> Produit (personnel, EquipmentItem, etc.)

... où hasMany client Stores, Store hasMany Products (hasMany Staff, hasMany EquipmentItem, etc.)

J'ai mis en place une relation HABTM entre Utilisateur et Client, qui est simple et accessible via la session Auth ou une méthode statique sur le modèle Utilisateur si nécessaire (voir la description afterFind ci-dessous).

À l'heure actuelle, je discute entre évaluer les résultats dans le rappel afterFind de chaque modèle, en vérifiant la relation avec le client en fonction du modèle que j'interroge sur les clients dont l'utilisateur actuel est membre. c'est-à-dire si le modèle actuel est Client, vérifiez l'identifiant; Si le modèle en cours est un magasin, vérifiez Store.clientid, et finalement, si produit, obtenez le parent Store à partir de Item.storeid et vérifiez Store.clientid en conséquence. Cependant, pour rester en ligne avec MVC correct, je renvoie true ou false à afterFind, puis je dois vérifier le retour de l'action appelant - c'est correct, mais je n'ai aucun moyen de penser à déterminez si Model-> find (ou Model-> read, etc.) renvoie false à cause d'un identifiant invalide dans la recherche ou à cause des permissions du Client dans afterFind; Cela signifie également que je devrais également modifier chaque action.

L'autre méthode avec laquelle j'ai joué est d'évaluer la requête dans app_controller.beforeFilter et en décomposant la requête en controller/action/id, je peux ensuite interroger le (s) modèle (s) approprié (s) et évaluer les champs le tableau Auth.User.clients pour déterminer si l'utilisateur a accès au client demandé. Cela semble correct, mais ne me laisse aucun moyen (afaik) de gérer/controller/index - il semble logique que les résultats de l'index reflètent l'appartenance du client.

Les défauts dans les deux incluent une longue liste de "règles" conditionnelles que je dois décomposer pour déterminer où le modèle/action/id courant est dans le contexte du client. Dans l'ensemble, les deux se sentent un peu fragile et alambiquée pour moi.

Y at-il une troisième option que je ne regarde pas?

Répondre

0

Cela ressemble à un travail pour Cake ACL. C'est un peu une courbe d'apprentissage, mais une fois que vous l'avez compris, cette méthode est très puissante et flexible. Les ACL de Cake (listes de contrôle d'accès) permettent de faire correspondre les utilisateurs aux contrôleurs jusqu'au niveau CRUD (Créer une mise à jour de mise à jour). Pourquoi l'utiliser?

1) Le code est déjà là pour vous. L'AuthComponent l'a déjà intégré. 2) Il est puissant et intégré pour vous permettre de contrôler les permissions de chaque action de votre site. 3) Vous pourrez trouver de l'aide auprès d'autres développeurs de gâteaux qui l'ont déjà utilisé. 4) Une fois que vous l'aurez configuré la première fois, il sera beaucoup plus facile et plus rapide d'implémenter des permissions de site complètes sur n'importe quelle autre application.

Voici quelques liens:

http://bakery.cakephp.org/articles/view/how-to-use-acl-in-1-2-x http://book.cakephp.org/view/171/Access-Control-Lists http://blog.jails.fr/cakephp/index.php?post/2007/08/15/AuthComponent-and-ACL

Ou vous pouvez simplement google pour CakePHP ACL

+1

J'ai regardé dans ACL, et de ce que je l'ai lu, il ne fonctionne pas (et ce n'est pas recommandé) pour l'authentification par ligne ou par modèle, ce qui est ce que je cherche. – gravyface

+0

Je ne suis pas sûr de l'avantage des permissions au niveau du modèle. Toutefois, avez-vous envisagé d'utiliser les UUID et de créer une seule table HABTM d'autorisations entre toutes vos tables. Vous pouvez ensuite utiliser la liaison de modèle personnalisée pour vérifier les autorisations. Dans votre beforeFind il suffit de mettre un bindModel ('permissions'). Ensuite, la gestion des autorisations aurait des bindModels personnalisés, etc. – Dooltaz

Questions connexes