Un mémo lors de l'examen de la gestion des rôles et des droits d'accès dans Rails
・ Cancancan ・ Expert ・ Banken
Le fichier de paramétrage semble simple et les experts ou banken qui peuvent être écrits avec ruby semblent être faciles à faire. En termes de popularité, expert. Cependant, en regardant le glissement de banken, banken semble être bon parce que "le créateur a effacé les points d'insatisfaction du cancancan et du pundit".
・ Rolify
Un aperçu de chaque bijou sera donné plus tard.
De chaque bijou
Les diapositives suivantes permettent de comprendre facilement la différence entre cancancan, pundit et banken. https://speakerdeck.com/kyuden/rails-authorization
Ce qui suit est une référence pour comparer cancancan et pudit. https://www.icare.jpn.com/dev_cat/pundit%E3%81%A8cancancan%E3%81%AE%E6%AF%94%E8%BC%83/
Je vois la description selon laquelle la sorcellerie est plus facile à personnaliser pour l'authentification, donc je pense que la sorcellerie est plus sûre en tant que modèle à usage général.
Donc Certification: sorcellerie Autorisation: bunken (ou pundit) Autorisation: rolify ou original
L'image semble être à usage général.
Cela ressemble à la structure du blog gunosy ci-dessous, ou est traîné
https://tech.gunosy.io/entry/gunosy-admin-rails
https://github.com/CanCanCommunity/cancancan
Ce que tu peux faire -Les conditions d'autorisation peuvent être définies dans un fichier de classe de capacité par modèle + action pour chaque autorité.
Utilisation de base -Créez une classe Ability et écrivez-la dans votre propre DSL. -La manière de base d'écrire est "peut / ne peut pas agir sur le nom, le modèle, la condition".
def initialize(user)
can :read, Post, public: true
if user.present?
can :read, Post, user_id: user.id
if user.admin?
can :read, Post
end
end
end
Démérite ・ Il y a un coût d'apprentissage pour la notation originale -En gros, l'autorité * can / canont pour chaque modèle est écrite dans un seul fichier de capacité, donc il est facile de le développer. S'il existe de nombreuses branches conditionnelles, les perspectives seront pires.
URL de référence https://qiita.com/senou/items/e28ff548e93ad0eeed3f https://qiita.com/naoki85/items/266c8d7ab469cc6ab1fe https://qiita.com/umanoda/items/679419ce30d1996628ed https://happy-teeth.hatenablog.com/entry/2018/12/09/002905
https://github.com/varvet/pundit Ce que tu peux faire -Vous pouvez créer une classe de stratégie pour chaque modèle et définir les conditions d'autorisation pour le nom de l'action. ・ Peut être écrit avec du rubis. ・ * Une seule politique peut être associée à un modèle. Lorsqu'on se réfère au même modèle sur l'API et sur l'écran normal, il sera décrit dans un fichier de stratégie.
Utilisation de base -Créer un fichier de politique pour chaque modèle. -Ecrire une fonction pour le jugement de condition dans le fichier de politique. -Lors de son utilisation, exécutez l'autorisation du contrôleur, etc. pour recevoir le résultat du jugement et le contrôler.
Démérite -Une seule définition est appliquée au nom de l'action Model +. Si le contrôle est séparé entre le contrôleur d'écran et le contrôleur API, il semble que cela ne sert à rien si les noms d'actions sont dupliqués.
URL de référence https://qiita.com/senou/items/e28ff548e93ad0eeed3f
https://github.com/kyuden/banken
Ce que tu peux faire La restriction selon laquelle "le modèle et la politique doivent être un à un" dans pundit est supprimée, et les conditions d'autorisation pour l'action peuvent être décrites pour chaque contrôleur.
Utilisation de base -Générer un fichier de fidélité pour chaque contrôleur. -Saisissez les conditions d'autorisation pour chaque nom d'action et exécutez l'autorisation du côté du contrôleur pour émettre un jugement.
Démérite ・ Le nombre d'utilisateurs est inférieur à celui de l'expert et du cancancan. ・ Comparé à pundit, il n'y a pas de fonction de portée
URL de référence Partage de diapositives https://speakerdeck.com/kyuden/rails-authorization https://github.com/kyuden/banken Document japonais
https://github.com/RolifyCommunity/rolify
Ce que tu peux faire Le rôle peut être associé au modèle utilisé pour l'authentification tel que Utilisateurs. Un modèle et une méthode pour le rôle sont générés. Un bijou pour accorder l'autorité, pas le mécanisme d'autorisation de l'étape précédente. Le rôle peut être défini plusieurs fois pour un utilisateur.
Utilisation de base -Définissez un rôle spécifique avec add_role () lors de la création d'un utilisateur. -Si l'utilisateur a des privilèges spécifiques peuvent être obtenus avec user.has_role? (), Alors vérifiez le rôle là-bas. Le contrôle d'accès qui en résulte est défini avec cancancan ou pundit.
URL de référence https://qiita.com/tatsurou313/items/0f632887d049e9503e3b https://github.com/RolifyCommunity/rolify
Il existe également des logiques d'authentification et de chnce claires pour l'authentification, mais elles sont omises.