0

Ok, supposons avoir ce schéma db (relation):approche de limiter la visibilité des données

|User | (1-->n) |Customer | (1-->n) |Car | (1-->n) |Support | 
|--------|   |---------|   |-----|   |-----------| 
|id  |   | user_id |   |Brand|   |Description| 
|username|   |lastname |   |PS |   |Cost  | 
|password|   |firstname|   |seats|   |hours  | 
|...  |   |..  |   |... |   |...  | 

Le tableau est généré par l'utilisateur Authlogic.

J'ai 2 utilisateurs enregistrés, chacun a ses clients, etc. Avec Authlogic, je ne peux autoriser que les utilisateurs authentifiés à accéder aux contrôleurs/vues. C'est bien, c'est pour ça que Authlogic est fait.

Maintenant je dois être sûr que l'utilisateur n ° 1 n'atteindra jamais les informations appartenant aux clients de l'utilisateur n ° 2.

En d'autres termes: si l'utilisateur # 1 va à http://myapp.com/cars il verra la liste des voitures appartenant aux clients de l'utilisateur # 1

si la voiture avec l'id = 131 appartient au client de l'utilisateur # 1, seul l'utilisateur n ° 1 doit pouvoir accéder à cette information (http://myapp.com/car/1). Si l'utilisateur n ° 2 insère dans le navigateur le même lien, il ne doit pas être en mesure de voir cette information.

Certaines personnes m'ont suggéré de créer une relation entre l'utilisateur et chaque table db afin de vérifier si un enregistrement est associé à current_user.

Qu'en pensez-vous? Quelle est la meilleure approche/solution?

Répondre

1

Vous avez donc 2 choses:

  1. En page d'index du contrôleur de voitures que les voitures qui appartiennent à l'utilisateur en cours doivent être affichés.
  2. Vous souhaitez limiter les pages d'affichage au propriétaire.

Quant à l'indice je suggère quelque chose comme:

def index 
    # find logic 
    @cars = Car.find(:all,:conditions=>{:customer_id => current_user.customers.collect(&:id)}) 
    # whatever else 
    # ... 
end 

Et la page show:

def show 
    # ..... 
    # after the find logic 
    redirect_to :index unless current_user.customers.collect(&:id).include? @car.customer_id 
    # whatever else 
    # ... 
end 

Cette approche est ok pour la plupart des cas, mais une meilleure approche pour la performance consiste à ajouter une colonne user_id à la table costumers, cela s'appelle la dénormalisation mais c'est acceptable pour les performances.

+0

Merci khelll. On dirait que la dénormalisation de DB est la voie à suivre. J'ai donc besoin d'une relation 1-> n entre l'utilisateur et chaque table (dans ce cas, dans la voiture et le support). – Irukandji

+0

Oui, vous feriez mieux de le faire. – khelll