Rails : Accès à current_user à partir d'un modèle en Ruby on Rails

Question

Je dois mettre en œuvre un contrôle d'accès à grain fin dans une application Ruby on Rails. Les permissions des utilisateurs individuels sont sauvegardées dans une table de base de données et j'ai pensé qu'il serait préférable de laisser la ressource respective (c'est-à-dire l'instance d'un modèle) décider si un certain utilisateur est autorisé à lire ou écrire dans cette table. Prendre cette décision dans le contrôleur à chaque fois ne serait certainement pas très DRY.
Le problème est que pour faire cela, le modèle doit avoir accès à l'utilisateur actuel, pour appeler quelque chose comme may_read ?( current_user , attribute_name ). En général, les modèles n'ont cependant pas accès aux données de session.

Il existe de nombreuses suggestions pour sauvegarder une référence à l'utilisateur actuel dans le fil de discussion actuel, par exemple dans cet article de blog . Cela résoudrait certainement le problème.

Les résultats voisins de Google m'ont cependant conseillé de sauvegarder une référence à l'utilisateur actuel dans la classe User, ce qui, je suppose, a été pensé par quelqu'un dont l'application n'a pas à accueillir beaucoup d'utilisateurs à la fois. ;)

Pour faire court, j'ai l'impression que mon souhait d'accéder à l'utilisateur actuel (c'est-à-dire aux données de session) à partir d'un modèle vient de moi le faire mal .

Pouvez-vous me dire en quoi j'ai tort ?

Answer 1

Je dirais que votre instinct vous pousse à garder current_user du modèle sont correctes.

Comme Daniel, je suis pour les contrôleurs maigres et les mannequins obèses, mais il y a aussi un partage clair des responsabilités. Le but du contrôleur est de gérer la demande entrante et la session. Le modèle doit être capable de répondre à la question "L'utilisateur x peut-il faire y à cet objet ?", mais il est absurde qu'il fasse référence à l'objet current_user . Et si vous êtes dans la console ? Et si c'est une tâche cron qui s'exécute ?

Dans de nombreux cas, avec les bonnes API de permissions dans le modèle, cela peut être géré avec une seule ligne before_filters qui s'appliquent à plusieurs actions. Cependant, si les choses deviennent plus complexes, vous voudrez peut-être implémenter une couche séparée (éventuellement dans le module lib/ ) qui encapsule la logique d'autorisation la plus complexe afin d'éviter que votre contrôleur ne devienne trop volumineux et que votre modèle ne soit trop étroitement lié au cycle demande/réponse du Web.

Answer 2

Bien que de nombreuses personnes aient déjà répondu à cette question, je voulais juste ajouter rapidement mon grain de sel.

L'utilisation de l'approche #current_user sur le modèle utilisateur doit être mise en œuvre avec prudence en raison de la sécurité des fils.

Il est possible d'utiliser une méthode de classe/singleton sur User si vous n'oubliez pas d'utiliser Thread.current pour stocker et récupérer vos valeurs. Mais ce n'est pas aussi simple que cela car vous devez également réinitialiser Thread.current afin que la prochaine requête n'hérite pas des permissions qu'elle ne devrait pas avoir.

Ce que je veux dire, c'est que si vous stockez l'état dans des variables de classe ou singleton, n'oubliez pas que vous jetez la sécurité des fils par la fenêtre.

Answer 3

Le contrôleur doit indiquer à l'instance du modèle

Travailler avec la base de données est le travail du modèle. La gestion des requêtes web, y compris la connaissance de l'utilisateur pour la requête en cours, est le travail du contrôleur.

Par conséquent, si une instance de modèle a besoin de connaître l'utilisateur actuel, un contrôleur doit le lui indiquer.

def create
  @item = Item.new
  @item.current_user = current_user # or whatever your controller method is
  ...
end

Cela suppose que Item a un attr_accessor pour current_user .

(Note - J'ai d'abord posté cette réponse sur une autre question, mais je viens de remarquer que cette question est un doublon de celle-ci).

Answer 4

Eh bien, je pense que current_user est finalement une instance d'utilisateur, alors, pourquoi ne pas ajouter ces permissions à l'instance d'utilisateur ? User ou au modèle de données auquel vous voulez que les permissions soient appliquées ou interrogées ?

Je pense que vous devez restructurer votre modèle d'une manière ou d'une autre et passer l'utilisateur actuel comme un paramètre, comme faire :

class Node < ActiveRecord
  belongs_to :user

  def authorized?(user)
    user && ( user.admin? or self.user_id == user.id )
  end
end

# inside controllers or helpers
node.authorized? current_user

Answer 5

J'utilise le plugin Declarative Authorization, et il fait quelque chose de similaire à ce que vous mentionnez avec current_user Il utilise un before_filter pour tirer current_user et le stocker là où la couche modèle peut l'atteindre. Ça ressemble à ça :

# set_current_user sets the global current user for this request.  This
# is used by model security that does not have access to the
# controller#current_user method.  It is called as a before_filter.
def set_current_user
  Authorization.current_user = current_user
end

Je n'utilise pas les fonctions de modèle de l'autorisation déclarative. Je suis partisan de l'approche "Skinny Controller - Fat Model", mais j'ai le sentiment que l'autorisation (ainsi que l'authentification) est quelque chose qui appartient à la couche contrôleur.