2009-03-04 3 views
2

J'ai une application Rails où les utilisateurs ont des adhésions aux projets (et d'autres choses, polymorphiquement). Les utilisateurs ont également des rôles. Je souhaite que les projets Utilisateur # fonctionnent comme une recherche ActiveRecord normale, mais je souhaite également que les administrateurs aient accès à tous les projets.Comment contrôler les ressources de l'utilisateur, mais laisser les administrateurs tout voir?

Pendant un certain temps que je suis en train de faire ceci:

class User < ActiveRecord::Base 
    has_many :memberships, :dependent => :destroy 

    def projects 
    if has_role?(:admin) 
     Project.find(:all) 
    else 
     Project.find(:all, :include => :memberships, :conditions => ["memberships.user_id = ?", id]) 
    end 
    end 
end 

class Project < ActiveRecord::Base 
    has_many :memberships, :as => :member, :dependent => :destroy 
end 

class Membership < ActiveRecord::Base 
    belongs_to :user 
    belongs_to :member, :polymorphic => :true 
end 

Mais je voudrais vraiment faire quelque chose plutôt comme ceci:

class User < ActiveRecord::Base 
    has_many :memberships, :dependent => :destroy 
    has_many :projects, :through => :memberships, :source => :member, :source_type => "Project" 
end 

pour que je puisse utiliser named_scope plus régulièrement (par exemple ' alfred.projects.recent.active '). Le

Cela fonctionne si vous ajoutez automatiquement de nouvelles adhésions pour les administrateurs, mais cela devient rapidement incontrôlable.

Je souhaite conserver l'interface des projets Utilisateur #. Quelle est la bonne piste ici?

Merci beaucoup.

+0

Merci pour toutes les excellentes suggestions! Il existe peut-être un autre moyen d'attaquer ceci: existe-t-il un moyen simple de faire en sorte qu'un tableau d'objets ActiveRecord se comporte comme une association AR, de sorte que named_scope et find fonctionnent? c'est-à-dire des projets = Project.find (: all); projects.active.recent - Merci encore à tous! – scottburton11

Répondre

1

Take a look at activefx's restfull authenticaion tutorial: (tutoriel d'authentification reposant) Il est une application de rails avec les caractéristiques suivantes:

CARACTÉRISTIQUES COURANT

- Login/Logout 
- Restful, with the exception of the "activate" action 
- Namespaced admin and user sections 
- OpenID Authentication with support for incomplete OpenID profiles 
- Roles and permissions 
- Administrative user controller 
- Set roles, activate, enable/disable users 
- Login, permission, and access denied redirection system 
- Member list and public profiles for logged in users 
- Activation, with option to resend activation code 
- Beta invitation system 
- easy on/off functionality, add/remove invites, send emails to 
- pending users 
- Forgot Password/Reset Password 
- Change Password 
- Failed login attempts database logging 
- Recaptcha displayed for more than 5 failed logins 
- Helper methods (link_to_user, if_admin?, etc.) 

This thread will explain how you give owner and administrator access. #28.

Bonne chance.

+0

Votre lien github renvoie l'erreur poulpe: Cette page n'existe pas! http://github.com/activefx/restful_authentication_tutorial/tree/master Les caractères de soulignement ont été modifiés d'une manière ou d'une autre – srboisvert

+0

Hmmm vous avez raison:/J'ai mis à jour le lien. Pourquoi ne puis-je pas utiliser les traits de soulignement? – atmorell

+0

Merci atmorell. "has_ " est un bon moyen de résumer ceci pour des ressources uniques, et aidera à refactoriser un autre code que j'utilise. Ma seule préoccupation est qu'il est identique à ma méthode de projets User # actuelle par rapport à quelque chose comme current_user.projects.find (: all). Merci de répondre! – scottburton11

0

Personnellement, je n'aime pas répandre les problèmes d'autorisation entre les modèles de la façon dont vous essayez de le faire.

Il y a plusieurs raisons à cela (la principale étant qu'à la fin cela conduit généralement à un design non-RESTful). L'autre réside dans le problème des méthodes ambivalentes.

Pensez-y. Que signifie user.projects sur votre système? Dans votre modèle, il a deux significations: cela signifie

  1. tous les projets que l'utilisateur est impliqué,
  2. tous les projets qui existent.

Si vous modélisiez votre système de cette façon, vous deviez vous retrouver avec un tas de méthodes avec de nombreuses significations différentes, ie. (pensez à un cas dans lequel vous avez trois, quatre ou plusieurs rôles), ce qui n'est pas une bonne pratique. Il y a plus de raisons, cependant. Par exemple. Et si un utilisateur avait plus d'un rôle? Les administrateurs sont généralement des utilisateurs normaux.

Quelle est alors la "bonne" solution? Eh bien, il y en a peut-être plus, mais celui que j'aime et que j'utilise maintenant est celui utilisé par rails-authorization-plugin. Définissez les rôles dans les modèles et implémentez la logique d'autorisation dans les contrôleurs et les vues. Consultez le pour en voir plus.

Espérons que ça aide! Sinon, laissez un commentaire.

+0

Merci pour la réponse. J'essaie de garder la propriété et l'autorisation séparées, et c'est le seul cas où elles se croisent. Je suis d'accord que ça va probablement s'étendre à d'autres méthodes, mais je ne suis pas sûr si cela mérite de les mélanger complètement pour le moment. Je vais essayer Railins-autorisation-plugin. Merci! – scottburton11

Questions connexes