autorisation déclarative filter_access_to

Question

Je tente de sécuriser un contrôleur Rails3 en utilisant declareative_authorization.

Le contrôleur dispose des 7 actions RESTful, de trois actions membres personnalisées (activer, désactiver, copier) et d'une action de collecte personnalisée (publique). L'action "public" ne renvoie qu'un seul enregistrement. Seule l'action de collecte personnalisée (publique) doit être accessible aux utilisateurs authentifiés; le reste n'est disponible que pour l'utilisateur actuel.

has_permission_on :foos, :to => :public 
has_permission_on :foos, :to => [:full_control, :copy, :activate, :deactivate] do 
    if_attribute :user => is {user} 
end 

privilege :full_control, :includes => [:index, :show, :new, :create, :edit, :update, :destroy] 

Les 4 actions personnalisées sont définies dans le fichier routes.rb:

resources :users do 
    resources :foos do 
    collection do 
     get :public 
    end 
    member do 
     post :activate, :copy, :deactivate 
    end 
    end 
end 

Un Utilisateur: has_many Foos; Un Foo: appartient à un utilisateur. Le contrôle d'accès 'standard' (filter_resource_access: nested_in =>: user), tel que défini dans le FoosController, semble contrôler l'accès aux 7 actions RESTful, mais ne contrôle pas l'accès aux 4 autres (comme prévu).

Quand je change le FooController à:

filter_access_to :all, :nested_in => :users, :attribute_check => true 

Je reçois une erreur qui se lit « Impossible de trouver Foo sans carte d'identité ».

Questions:

1. La documentation semble indiquer que: before_filter sera appelé automatiquement charger le modèle Foo lorsque filter_access_to est utilisé. Est-ce que je me trompe? Ai-je besoin d'une configuration supplémentaire de filter_access_to? Dois-je configurer manuellement un: before_filter?
2. Dois-je également ajouter use_access_control au modèle pour mes besoins? Je ne suis pas très clair quand il faut ajouter un contrôle d'accès au modèle quand il y a un contrôle d'accès dans le contrôleur.
3. La documentation décrit un privilège nommé 'create' - il est défini comme suit: privilege: create,: includes =>: new. De plus, pour la nouvelle action, ce privilège inclut-il automatiquement l'action: create en raison de son nom?
4. Si le fichier authentication_rules.rb est modifié, le serveur doit-il être redémarré pour que les nouvelles règles soient appliquées?

Answer 1

Je pense que le filtre avant automatique, s'il existe, est assez limité. J'ai toujours dû écrire le mien avant les filtres en fonction du contexte. Par exemple, pour l'affichage de l'index, sauf si la permission est la même pour toutes les instances du modèle, vous devez avoir une instance de modèle appropriée au contexte actuel. Comme un utilisateur qui consulte un index de publications, vous voudrez créer un nouveau message fictif pour l'utilisateur, ou charger son premier message, mais le code fictif est plus sûr car le premier n'existe peut-être pas. En général, j'ai un constructeur fictif pour index et tout le reste peut tester tout ce qui doit être vu (ou touché).

Le contrôleur a été assez bon pour moi jusqu'à présent, donc le niveau du modèle n'est certainement pas NÉCESSAIRE. Cela ne veut pas dire que cela n'augmenterait pas la sécurité, mais je ne suis pas expert quand exactement cela deviendrait important. Je ferais l'hypothèse que ce serait quand vous avez un modèle touché par de nombreux contrôleurs (par exemple contrôleurs sans modélisme) et vous voulez être sûr que rien ne se faufile par.

Je n'ai pas utilisé de privilèges, donc je ne suis pas sûr, mais je suppose que l'héritage magique que vous décrivez ne se produit pas.La création d'autorisations qui ne sont pas spécifiquement demandées semble être une approche très bâclée.

Non, aucun redémarrage requis - au moins en mode développement.