Dev Faq
7
votes

Structure de modèle Rails pour les utilisateurs

Je suis nouveau dans les rails et je travaille sur ma deuxième application Rails.

L'application aura des rôles différents pour les utilisateurs, mais certains utilisateurs auront plusieurs rôles.

Chaque utilisateur du site sera un artiste. Certains utilisateurs auront le rôle d'un modérateur.

Comment puis-je structurer cela? Dans certaines applications PHP que j'ai utilisées, il n'y a qu'un seul utilisateur, puis une colonne de base de données pour is_admin, etc. Mais j'ai examiné la source des applications de rails et j'ai vu des modèles distincts pour l'utilisateur et l'administrateur, etc. Bien que je Je ne sais pas pourquoi.

Donc, devrais-je avoir un modèle utilisateur unique avec un attribut de rôle, qui pourrait être modérateur, puis appeler simplement les utilisateurs "artistes" dans mes vues, itinéraires, etc.?

ou dois-je avoir un modèle utilisateur, un modèle de modérateur qui en hérite et un modèle d'artiste qui appartient à l'utilisateur?

Je suis vraiment confus.

0 commentaires

6 Réponses :

2
votes

Je pense que vous n'avez pas à créer différents modèles car vous n'avez pas de champs spécifiques pour chacun. Vous devez donc simplement définir le «rôle» de chaque utilisateur. Deux options: Créez une table de rôle ou ajoutez un champ de rôle dans l'utilisateur de la table. Les deux solutions fonctionnent, la seconde est plus flexible mais moins optimisée.

Mais, dans votre cas particulier, vous n'avez pas de gestion de rôle complexe, vous pouvez donc trouver une solution plus simple. Si tous vos utilisateurs sont des artistes, vous n'avez pas à spécifier cela dans votre code, il est contenu dans la description implicite de ce qu'un utilisateur est. Donc, vous devez simplement enregistrer si un utilisateur est un administrateur ou non et je pense que la meilleure solution consiste à créer un champ booléen "is_admin".

Après cela, vous devrez créer une partie avant_filter dans vos contrôleurs protégés , comme celui-ci: xxx

et vous pouvez avoir des demandes simples comme celle-ci: xxx

Si vous cherchez un plus complet Système d'autorisation Vous pouvez vérifier ce petit bijou: https://github.com/ryanb/cancan

Mais je pense que ce n'est pas le cas pour le moment. Si vous avez un problème simple, recherchez une solution simple!

2 commentaires

Valeurs booléennes en Arr Produce FOO? Idéal pour les conditionnels et Ruby a un meilleur si non sous la forme de sauf si . Combinant ceux ensemble: Redirect_To: ROOTINE SAUF CURCENT_USER.IS_ADMIN?

+1 pour des solutions simples. La bonne chose à propos de Ruby est que vous pouvez utiliser le champ booléen et garder le is_admin? Interface lorsque vous passez à un modèle distinct ou quelque chose d'autre.

7
votes

Vous pouvez rechercher des gemmes Devise et Cancan. Cette paire est une combinaison vraiment puissante. Cela rend deux modèles utilisateur et rôle. En tant que rôle, vous pouvez créer de nouveaux rôles sans créer de nouveaux modèles pour eux. Bien qu'il crée une capacité de modèle, vous pouvez ici définir des règles d'accès pour les rôles.

manuel: http: // www.tonyamoyal.com/2010/07/28/Rails-Authentication-with-devise-and-Cancan-Customizing-Devise-Controls/ P>

Ici, vous trouverez les sources de Devise et Cancan et Wikies: P>

https://github.com/plataformatec/devise P >

https://github.com/ryanb/cancan p>

My Les modèles ressemblent à ceci: p>

rôle.rb p> xxx pré>

user.rb p> xxx pré>

capacité. RB P> 

class YourController < ApplicationController
  before_filter :authenticate_user!
  load_and_authorize_resource

  ...

end

3 commentaires

Cela aurait été ma suggestion. Ce que j'aime à propos de cette approche, c'est qu'elle encourage la séparation de la politique commerciale à partir du reste de la logique de votre application.

Oui, cette séparation donne de bonnes capacités flexibles. Je suis utilisé dans un projet unique, où les développeurs ont fait un système d'authentification très inconfortable, où l'ajout de nouveaux rôles et capacités que je devais écrire beaucoup de code dans chaque contrôleur et modèle. Je suis passé beaucoup de temps à éliminer le système ancien et à proximité de deux heures pour l'installation et la configuration du congage et du Cancan. Maintenant je suis content. Et quand je vais avoir du temps libre, je prévois d'écrire une interface utilisateur pour gérer les rôles et les capacités. Avec ces systèmes, cette tâche est devenue simplement.

Nous avons utilisé cela dans plusieurs applications et nous trouvons également la mix Devise-Cancan pour être l'approche «Best-de Race». Il est rapidement adopté par de nombreux orgs comme la norme de cette année pour l'authentification / l'autorisation.

2
votes

Si vous devez avoir du code spécifique à et à jouer, tel qu'un administrateur ou un modérateur, une autre solution serait de créer un modèle d'utilisateur de base que toutes les autres classes héritent de. Vous pouvez ensuite créer une classe d'administration et une classe de modérateur qui hériter du modèle utilisateur. Cela signifierait que vous pouvez éviter de vérifier constamment le rôle des utilisateurs dans votre code par exemple. actuel_user.do_some_admin_thing si actuel_user.is_admin? . Vos cours ressembleraient à quelque chose comme ceci xxx

Dans ce cas, la classe d'utilisateurs dispose des privilèges les plus élémentaires, les modérateurs peuvent faire tout ce que les utilisateurs peuvent ainsi que les méthodes et les administrateurs spécifiques du modérateur puissent faire tout ce que les utilisateurs et les modérateurs peuvent faire plus les méthodes spécifiques de l'administrateur.

Tous les différents rôles d'utilisateur utiliseraient la même table dans la base de données, mais vos préoccupations sont soigneusement séparées dans des classes qui évitent des conditionnels excessives grâce à votre code de contrôle de votre code quel rôle l'utilisateur est tout le temps. .

Création de nouveaux utilisateurs serait simple aussi admin.new: nom => 'BOB' La classe d'administration s'occupe ensuite de la manière dont un utilisateur est défini comme un administrateur qui fournit Belle interface où vous n'avez pas besoin de connaître le fonctionnement intérieur du système de rôle pour interagir avec les utilisateurs.

2 commentaires

Veuillez modifier votre question pour être explicite sur le fait que cela utilise l'héritage de la table unique et le lien vers la documentation officielle des rails.

La question ne parle pas de comportement différent pour différents utilisateurs, juste une autorisation différente de faire différentes choses. À moins que l'instance de modèles utilisateur se comportent différemment, il est trop complexe de créer différentes sous-classes. La surutilisation de l'héritage est un anti-motif.

1
votes

Bien que je suis d'accord sur la combinaison de Devise et Cancan est puissant et fonctionne. Regardons-la avec une association de conservation et une délégation de perspective différentes.

Association: dans la programmation orientée objet, l'association définit un relation entre les classes d'objets qui permet un objet cas pour faire effectuer une autre action en son nom.

Délégation: La délégation permet au comportement d'un objet d'être défini en termes de comportement d'un autre objet. Le terme La «délégation» fait référence à la délégation de responsabilité. Le principal l'accent mis sur la délégation est sur le message qui passe lorsqu'un objet pourrait déléguer la responsabilité d'un message qu'il ne pouvait pas gérer à des objets cela pourrait potentiellement (ses délégués).

Avec cela, que si nous conçons notre utilisateur et nos rôles comme celui-ci. Il n'y a pas de classe de rôle et l'utilisateur n'hérite ni ne spécialisait une classe particulière (artiste, administrateur), toute la classe (rôle) contenant l'objet utilisateur et le délégué. La façon dont je pense et que je pense que cela puisse mettre en œuvre avec des rails est quelque chose comme ceci: xxx

ceci modèle de classe de rôle est décrit par Francis G. Mossé dans son article sur les rôles de modélisation.

0 commentaires
1
votes

Ceci est la configuration de base, pour le Autorisation déclarative Gem, j'utilise. Mais vous pouvez simplement utiliser ceci comme c'est sans le gemme, si vos exigences d'autorisation ne sont pas plus que de poser le type de rôles que l'utilisateur a.

Il nécessite des rôles code>, etc. Donc, cela pourrait ne pas vraiment être votre fantaisie. P> 

class Role < ActiveRecord::Base
  belongs_to :user
end

class User < ActiveRecord::Base
  has_many :roles

  def role_symbols
    roles.map { |r| r.title.to_sym }
  end

  def admin?
    has_role?(:admin)
  end
  # include more role booleans or write some ruby magic to be DRY
  # ...

  def has_role?(r)
    role_symbols.include?(r.to_sym)
  end
end

# give or take
user = User.new
user.roles << Role.new :title => "admin"
user.roles << Role.new :title => "artist"

user.role_symbols # => [:admin, :artist]
user.admin? # => true
user.has_role?(:artist) # => true

0 commentaires
0
votes

Vous pouvez avoir deux modèles utilisateur et rôle. Et le rôle appartient à l'utilisateur.

Spécifiez le rôle des utilisateurs (comme admin, modérateur) dans le modèle de rôle.

0 commentaires

Articles qui pourrait vous intéresser :

Problème lors de l'installation de ruby-2.7.1
commande pry introuvable après l'installation de gem
nokogiri ne s'installe pas dans ruby 2.7.1 centos 7.2
Comment masquer le titre du formulaire qui apparaît à l'intérieur d'une balise de légende lors de la génération de cases à cocher pour une association à l'aide de simple-form?