I have a RESTful User class, but the User actions (minus new and create) require an application user to be logged in. This leads me to a bit of a REST conundrum. The edit action for a specific User is obviously access with an url like http://www.domain.com/users/1;edit But I do not want the User with ID 1 to be able to edit User with ID 2's with http://www.domain.com/users/2;edit I am curious as to how people are handling situations like this. I am currently using a before_filter on these actions which checks if the User ID stored in the session is the same as the params ID. If not, it silently redirects to the same action, but with their ID. For example, a request of http://www.domain.com/users/2 from the application user logged in with an ID of 1 is redirected to http://www.domain.com/users/1 So yeah, just curious what other people think about this issue.
on 2007-03-02 10:50
on 2007-03-02 16:36
As you alluded to, in all my controllers I have a before_filter that verifies and pre-populates instance variables of the main object(s) in the page. If you're using AAA, you can just access 'current_user' object which should always be the logged in user, alleviating the issue of forgery. This renders the user id in the URL uneccessary altogether. If you're not using AAA, you can set a before_filter such as: def set_user @user = User.find(session[:user_id]) end So then in your update method, you would just do a @user.update_attributes!(params). As for other controllers, it's good to ensure the association isn't forged as well. So in, say, an AssetsController you could have a before_filter like: def set_variables @user = User.find(session[:user_id]) @asset = @user.assets.find(params[:id]) end hope that helps, ed