Existe-t-il une approche de consensus pour mettre en œuvre des rôles d'utilisateur lorsque vous utilisez des itinéraires de ressources reposants?
Dis que j'ai les ressources suivantes: p> et disent ensuite que j'ai deux types d'utilisateurs: clients et agents. Les deux se connecteront au système, mais avec différents ressources et fonctionnalités de ressources basées sur leurs rôles. Par exemple: p> Les clients peuvent accéder à: p> Les agents peuvent accéder: p> Laquelle des 4 approches générales ci-dessous sera plus propre et plus flexible? p> Des contrôleurs distincts dans des dossiers de rôle et des ressources dans des espaces de noms, par exemple: P>
TicketController
def create
if @role == :customer
#buy ticket
elsif @role == :customer
#sell ticket
end
end
3 Réponses :
Si vous utilisez le même modèle pour les billets des clients et de l'agent, il ne devrait y avoir aucune différence majeure entre la manière dont ils sont traités dans le contrôleur. Donc, Créer une action sera toujours comme ceci: mais vos vues peuvent être simplement personnalisées:
Le modèle ne connaît pas l'utilisateur qui a toutefois authentifié. Qui est généralement géré par le contrôleur. En outre, l'OP est de demander le meilleur moyen de gérer la sécurité. Cela ne peut pas être personnalisé dans des vues. Qu'en est-il des connexions API? Comment appliquez-vous la sécurité pour différents rôles d'utilisateur là-bas? Vous ne voulez pas répéter le code, il doit donc être dans un endroit central, c'est-à-dire: contrôleur. Donc, la question est, comment pouvez-vous sérirez-vous gérer votre contrôleur pour ajouter ce type de contrôle précis sur les rôles et les autorisations des utilisateurs.
Je suggérerais d'utiliser une combinaison des deux dernières implémentations proposées. Ils adhèrent à une représentation reposante, ils ont mis l'autorisation au niveau approprié (contrôleurs), et c'est une mise en œuvre évolutive.
repos est essentiellement sur accédant à des noms avec des verbes . Vous voulez donc que des agents et des clients effectuent des actions (verbes) par rapport aux billets, aux utilisateurs et aux événements (noms). Afin de représenter avec précision ces noms, vous devriez avoir un contrôleur pour chacun. Les clients peuvent ensuite identifier la ressource qu'ils recherchent par l'URL, En adhérant à une architecture reposante, vous achetez dans le Fin à la fin Principe . Le paradigme de représentant des objets doit être responsable de cela. Cela ne devrait pas essayer d'authentifier. Ce n'est pas son travail. L'autorisation devrait se produire dans les contrôleurs. Je recommande vivement de regarder dans des gemmes comme CANCAN ou autorisation déclarative qui définit tout cela pour vous. Enfin, ce modèle évolutif. En gardant l'autorisation distincte de la représentation de vos ressources, vous devez seulement l'utiliser si vous en avez besoin. Cela conserve votre application, flexible et simple. http://example.com/events/22 . De là, vous pouvez utiliser le routage des rails pour représenter le contexte de diverses ressources, c'est-à-dire http://example.com/events/22/tickets en faisant quelque chose comme:
Pendant qu'ils traitent tous les deux à la création de billets, la vente de l'agent / du ticket vs. L'achat du client / billet semble assez différent pour moi qu'ils devraient être séparés. Finalement, ils pourraient davantage davantage car ils sont utilisés de manière si différente du début.
Il est possible d'avoir une fonctionnalité de contrôleur partagée avec des modules ou en hérité d'un contrôleur parent commun: P>
/agent/events/xx/tickets /agent/events/xx/edit # etc.