Rails modeling for a user

When building a rails app that allows a User to login and create data, is it best to setup a belongs_to :user association on every single model? For example, let's say a user can create Favorites, Colors and Tags.

And let's say Favorites has_many :tags and Colors also has_many :tags. Is it still important for Tags to belong_to :user assuming the User is the only person who has authority to edit those tags?

And a similar question along the same lines: When updating data in FavoritesController, I've come to the conclusion that you perform CRUD operations by always doing something like current_user.favorites.find(param[:id].update_attributes(param[:favorite]) so that they can defin开发者_开发知识库itely only update models that belong to them. Right?

Update Wasn't too happy with any of the answers, as no one really answered my question but instead went after the for-example-only Tags model suggesting better ways to do that. I'm assuming I was right, and models should belong_to :user. I also discovered some great security tips that address my questions here: http://asciicasts.com/episodes/178-seven-security-tips

As you describe the tags it seems that they are more of an aspect, so you can implement them as a polymorphic association. But you should do it many-to-many, as tags can be reused among users and taggable objects. Let's call the join model Tagging, which will be the one that belongs to user if you want to remember who created the tagging.

class Tag < ActiveRecord::Base
  has_many :taggings, :dependent => :destroy
  has_many :colors, :through => :taggings, :source => :taggable, :source_type => "Color"
  has_many :favorites, :through => :taggings, :source => :taggable, :source_type => "Favorite"
end

class Tagging < ActiveRecord::Base
  belongs_to :user
  belongs_to :taggable, :polymorphic => true
  belongs_to :tag  
end

class Color < ActiveRecord::Base
  belongs_to :user
  has_many :taggings, :as => :taggable
  has_many :tags, :through => :taggings
end

class Favorite < ActiveRecord::Base
  belongs_to :user
  has_many :taggings, :as => :taggable
  has_many :tags, :through => :taggings
end

class User < ActiveRecord::Base
  has_many :favorites
  has_many :colors
  has_many :taggings
  has_many :tags, :through => :taggings
end

As for the Favorite updating, I agree with you: you will mostly work within the scope of a user (most likely the currently logged in user).

It depends on your model. Both cases are valid but I'd discorage making a circular relationships like that. Having a hierarchy is more flexible. For example: User->Favorites->Tags (unless you want to tag users as well)

User.favorites.find(params[:id]).update_attributes(param[:favorite])

is what you mean I guess (syntax). Whoever calls the URL will perform that action. Dont rely on the fact that that URL is visible to one user only (owner of the favorite). You should have checks in place that the currently logged in user is the only one performing actions on the objects that belong to him.

The proposed mechanism sounds a bit too complex for me. I prefer the current_user way. Assume there is a current_user (following the authlogic way) in your authentication system, then simple add a user references (user_id) in every relevant table. Update the current_user for new or update record via a controller filter.

In the models, put relevant belongs_to :users accordingly, put enough has_many in users model if needed.

:has_many and :belongs_to in AR will explains the relationship between models, but not necessarily you have to use them in your models, the associaton between them will be already present in the tables as a foreign key.

But adding :has_many or :belongs_to to your models will give you extra methods to your model

ex:

class User < ActiveRecord::Base
 has_many :favorites


#def favorites
 #  Favorite.find_all_by_user_id(self.id)
 # end
end

If you mention has_many it will give a new method in your model called favorites, that method will be invisible (will be present in the AR).

Similarly for any association, if you are planning to use this kind of methods you should use associations in your models.