What's the best way to check if the current object belongs to the current user?
I want to only allow the power of deletion to the owner, but I'm struggling to build a controller function to accomplish this.
before_filter :signed_in_user, only: [:create]
before_filter :correct_user, only: [:edit, :update, :destroy]
...
def destroy
#event = Event.find(params[:id])
if #event.present?
#event.destroy
end
redirect_to root_path
end
private
def signed_in_user
unless signed_in?
store_location
redirect_to signin_path, notice: "Please sign in."
end
end
def correct_user
#event = current_user.events.find_by_id(params[:id])
rescue
redirect_to root_path
end
My current def correct_user allows any logged in user to make deletions.
Your correct_user method is already doing what you need to do: fetching the event with current_user.events.find. You can just delete the event-finding code from your destroy method and it should work correctly.
When I wrote my comment you had yet to added the destroy action code. Look carefully at the correct_user method:
def correct_user
#event = current_user.events.find_by_id(params[:id])
rescue
redirect_to root_path
end
Right there you are retrieving the event and storing it in an instance variable. More so, you are retrieving the event through the current_user. So it's scoped to the current_user, and only events that are owned by the current_user are exposed.
#event = current_user.events.find_by_id(params[:id])
Remember, correct_user is set in a before_filter, so it runs before the destroy action.
So, by the time the request gets to the destroy action, the event is already stored in an instance variable (#event). So there is already an event object for you to work with. You can reference that. There is no need to retrieve it again.
def destroy
#event = Event.find(params[:id]) #<- This line is redundant (and dangerous in this case)
... # snip
end
Change the destroy method to this.
def destroy
redirect_to root_path if #event.destroy
end
I was just about to add similar functionality! You have to check if the current user is signed in, and if their ID = the user_id of the object.
Something like
event = Event.find(params[:id])
if event.user_id == current_user.id
event.destroy
else
redirect_to :root, :notice => "You do not have permissions."
end
Related
I have my rails app and trying to add authority by adding a method made with gem called cancancan. so there are two methods below.
def find_review
#review = Review.find(params[:id])
end
def authorize_user!
unless can? :manage, #review
redirect_to product_path(#review.product)
end
end
and there are two cases. case 1: calling the methods inside destroy action
def destroy
find_review
authorize!
#product = #review.product
#reviews = #product.reviews
#review.destroy
end
and case 2: calling the methods using before_action method
before_action :find_review, :authorize!, only: [:destroy]
def destroy
#product = #review.product
#reviews = #product.reviews
#review.destroy
redirect_to product_path(#product), notice: 'Review is deleted'
end
I get that using before_action(case 2) redirects unauthorized user even before calling the action so it makes sense. What I am wondering is in case 1, why authorize method doesn't interrupt and redirect the user before destroying the review ? It actually redirects, but after deleting the review. but I thought ruby is synchronous..
As others have noted, your authorize! does not interrupt the request, only adds a header and then carries on with the destruction and whatnot. A good reliable way to interrupt the flow from within a nested method call is to raise an exception. Something like this:
class ApplicationController
NotAuthorizedError = Class.new(StandardError)
rescue_from NotAuthorizedError do
redirect_to root_path
end
end
class ReviewsController < ApplicationController
def authorize!
unless can?(:manage, #review)
fail NotAuthorizedError
end
end
def destroy
find_review
authorize! # if user is not authorized, the code below won't run
# because of the exception
#product = #review.product
#reviews = #product.reviews
#review.destroy
end
end
Update
There must be something off with your integration of cancan, because it does include an exception-raising authorize!. You should be able to do this:
def destroy
find_review
authorize! :manage, #review # can raise CanCan::AccessDenied
#product = #review.product
#reviews = #product.reviews
#review.destroy
end
Or, better
load_and_authorize_resource
def destroy
#product = #review.product
#reviews = #product.reviews
#review.destroy
end
In case 1 you need to return from method when doing redirect to halt execution, and use ActionController::Metal#performed? to test whether redirect already happended:
def authorize_user!
unless can? :manage, #review
redirect_to product_path(#review.product) and return
end
end
def destroy
find_review
authorize!; return if performed?
#product = #review.product
#reviews = #product.reviews
#review.destroy
end
There's no "asynchronous behaviour". redirect_to actually only adds appropriate headers for the response object, it's not halt execution of your delete request.
In case 1, you need to return from method when doing redirect to halt execution
return redirect_to product_path(#review.product)
In case 2, you have to make some change in you authorize method.
scenario 1. For a specific user role can't manage Review model at all
unless can?(:manage, Review)
redirect_to product_path(#review.product)
end
replace the instance variable with model name
scenario 2, some users in the specific role can manage the review, but others in some role can't mange review.
In this case, you need to load the review object before calling can function
def authorize_user!
find_review
unless can?( :manage, #review)
redirect_to product_path(#review.product)
end
end
I think my answer will help you.
I'm trying to make sure that people can't submit a create action if they submit an entry with an ID other than their own. For this, I have set up the test as following:
entries_controller_test.rb
def setup
#user = users(:thierry)
#other_user = users(:steve)
end
...
test "should redirect create action on entry with id that doesn't belong to you" do
log_in_as(#user)
assert_no_difference 'Entry.count' do
post :create, entry: { content: "Lorem Ipsum"*10, id: #other_user }
end
end
The outcome of the test is that Entry.count increases by one, therefore #user can create a post with ID #other_user (is the code correct to create an entry with ID of the other user?)
entries_controller.rb: My create action currently looks like this.
def create
#entry = #entries.build(entry_params)
if #entry.save
flash[:success] = "Your entry has been saved."
redirect_to root_path
else
flash.now[:danger] = "Your entry has not been saved."
render 'index'
end
end
The instance variable is being passed in to the action by calling before_action :correct_user on the action. Here's the correct_user method.
def correct_user
#entries = current_user.entries
redirect_to root_url if #entries.nil?
end
By the way, the create action is being called from the index page. I suspect the problem is indeed with authorization since my test can log in the user and create an actual entry.
Can anyone spot an issue?
Your code is only checking whether the current_user has some entries, but there is no validation on the user_id of the entry being submitted to the create action. Moreover, even if the user has no entries, the #entries variable will be [], which is not nil (so correct_user will never redirect to root). The correct check would have been #entries.empty?, but still the object would be created with an incorrect user, as long as the current_user already has some entries belonging to them.
The way I usually go about this is not to permit the user_id parameter (with strong_parameters), and by setting the ownership of new objects to the current_user. If you want to perform the check, your correct_user should look more like this:
def correct_user
unless current_user.id == params[:entry][:user_id]
flash[:alert] = "Some error message"
sign_out # This action looks like a hack attempt, thus it's better to destroy the session logging the user out
redirect_to root_url
end
end
I think this might work.
In your entries controller.
class EntriesController < ApplicationController
before_action :correct_user, only: [:edit, :update]
def correct_user
unless correct_user.id == params[:entry][:user_id]
else
redirect_to root_url
end
end
end
Preface: I'm using devise for authentication.
I'm trying to catch unauthorized users from being able to see, edit, or update another user's information. My biggest concern is a user modifying the form in the DOM to another user's ID, filling out the form, and clicking update. I've read specifically on SO that something like below should work, but it doesn't. A post on SO recommended moving the validate_current_user method into the public realm, but that didn't work either.
Is there something obvious I'm doing wrong? Or is there a better approach to what I'm trying to do, either using devise or something else?
My UsersController looks like this:
class UsersController < ApplicationController
before_filter :authenticate_admin!, :only => [:new, :create, :destroy]
before_filter :redirect_guests
def index
redirect_to current_user unless current_user.try(:admin?)
if params[:approved] == "false"
#users = User.find_all_by_approved(false)
else
#users = User.all
end
end
def show
#user = User.find(params[:id])
validate_current_user
#user
end
def new
#user = User.new
end
def edit
#user = User.find(params[:id])
validate_current_user
#user
end
def create
#user = User.new(params[:user])
respond_to do |format|
if #user.save
format.html { redirect_to #user, :notice => 'User was successfully created.' }
else
format.html { render :action => "new" }
end
end
end
def update
#user = User.find(params[:id])
validate_current_user
respond_to do |format|
if #user.update_attributes(params[:user])
format.html { redirect_to #user, :notice => 'User was successfully updated.' }
else
format.html { render :action => "edit" }
end
end
end
private
def redirect_guests
redirect_to new_user_session_path if current_user.nil?
end
def validate_current_user
if current_user && current_user != #user && !current_user.try(:admin?)
return redirect_to(current_user)
end
end
end
The authenticate_admin! method looks like this:
def authenticate_admin!
return redirect_to new_user_session_path if current_user.nil?
unless current_user.try(:admin?)
flash[:error] = "Unauthorized access!"
redirect_to root_path
end
end
EDIT -- What do you mean "it doesn't work?"
To help clarify, I get this error when I try to "hack" another user's account:
Render and/or redirect were called multiple times in this action.
Please note that you may only call render OR redirect, and at most
once per action. Also note that neither redirect nor render terminate
execution of the action, so if you want to exit an action after
redirecting, you need to do something like "redirect_to(...) and
return".
If I put the method code inline in the individual controller actions, they do work. But, I don't want to do that because it isn't DRY.
I should also specify I've tried:
def validate_current_user
if current_user && current_user != #user && !current_user.try(:admin?)
redirect_to(current_user) and return
end
end
If you think about it, return in the private method just exits the method and passes control back to the controller - it doesn't quit the action. If you want to quit the action you have to return again
For example, you could have something like this:
class PostsController < ApplicationController
def show
return if redirect_guest_posts(params[:guest], params[:id])
...
end
private
def redirect_guest_post(author_is_guest, post_id)
redirect_to special_guest_post_path(post_id) if author_is_guest
end
end
If params[:guest] is present and not false, the private method returns something truthy and the #show action quits. If the condition fails then it returns nil, and the action continues.
You are trying and you want to authorize users before every action. I would suggest you to use standard gems like CanCan or declarative_authorization.
Going ahead with this approach you might end up reinventing the wheel.
In case you decide on using cancan, all you have to do is add permissions in the ability.rb file(generated by rails cancan:install)
can [:read,:write,:destroy], :role => "admin"
And in the controller just add load_and_authorize_resource (cancan filter). It will check if the user has permissions for the current action. If the user doesnt have persmissions, then it will throw a 403 forbidden expection, which can be caught in the ApplicationController and handled appropriately.
Try,
before_filter :redirect_guests, :except => [:new, :create, :destroy]
should work.
This is because you are using redirect twice, in authenticate_admin! and redirect_guests for new, create and destroy actions.
"Render and/or redirect were called multiple times in this action. Please note that you may only call render OR redirect, and at most once per action."
That's the reason of the error. In show method, if you are neither the owner of this account nor the admin, you are facing two actions: redirect_to and render
My suggestion is to put all of the redirect logic into before_filter
I'm working through the Rails Tutorial, by Michael Hartl, and a question popped up, as I was creating an admin user.
I followed the instructions, and created an admin_user, who has access to the :destroy method. It also isn't attr_accessible, so people can't simply put a put request via the browser and change themeselves to admin.
But, I have a two-part question--
1) How would I make a user admin?
I though I would need to write something like this in the console
rails console
user = User.find(params[:101])
user.toggle!(:admin)
When I try that, I get
Undefined Local Variable or Method 'Params' for main:Object
2) Assuming that it is possible to make myself an admin, what's stopping other people from making themselves admin using a command line as well?
Here's a copy of the users_controller, I think Michael addressed this in the tutorial, and I followed his instructions, but I don't get how the below code prevents someone from going to the command line and making themselves admin
class UsersController < ApplicationController
before_filter :signed_in_user,
only: [:edit, :update, :index, :destroy]
before_filter :correct_user, only: [:edit, :update]
before_filter :admin_user, only: :destroy
def destroy
User.find(params[:id]).destroy
flash[:success] = "User destroyed."
redirect_to users_url
end
def index
#users = User.paginate(page: params[:page])
end
def show
#user = User.find(params[:id])
end
def new
unless signed_in?
#user = User.new
else
redirect_to #current_user
end
end
def create
unless signed_in?
#user = User.new(params[:user])
if #user.save
sign_in #user
flash[:success] = "Welcome to the Sample App!"
redirect_to #user
else
render 'new'
end
else
redirect_to #current_user
end
end
def edit
end
def update
if #user.update_attributes(params[:user])
flash[:success] = "Profile updated"
sign_in #user
redirect_to #user
else
render 'edit'
end
end
private
def signed_in_user
unless signed_in?
store_location
redirect_to signin_url, notice: "Please sign in."
end
end
def correct_user
#user = User.find(params[:id])
redirect_to(root_path) unless current_user?(#user)
end
def admin_user
redirect_to(root_path) unless current_user.admin?
end
end
I would really appreciate your help clearing things up!
User.find(params[:101]) is appropriate only for http browser requests. If you visit http://www.example.com?101=test, then you can use params[:101] with value "test". But in console you can't use params unless you declare it. In your case the wright way will be User.find(101), if 101 is user id.
Other people can't make them admin because you didn't add attr_accessible for admin field. How can they do it via command shell? They have no access to command line. If they are it's a serious security breach.
My code for post controller is as follows. What I'm trying to do is user should be able to delete his own posts, and admin_user can delete any posts. The following code make admin_user can delete posts, but for normal user, when trying to delete his own post, it redirect to root_path
It seems do_authentication doesn't work properly, a normal user is trying to be authenticated as an admin instead of "correct_user"
What could be wrong?
Thanks!
class PostsController < ApplicationController
before_filter :signed_in_user, only: [:index, :create, :destroy]
before_filter :do_authentication, only: :destroy
.
.
.
def destroy
#post.destroy
flash[:success] = "Post deleted!"
redirect_back_or user_path(current_user)
end
private
def do_authentication
correct_user || admin_user
end
def correct_user
#post = current_user.posts.find_by_id(params[:id])
redirect_to user_path(current_user) if #post.nil?
end
def admin_user
#post = Post.find_by_id(params[:id])
redirect_to(root_path) unless current_user.admin?
end
First of all I would suggest using cancan for authorization.
I think your problem is the return value of correct_user. You don't control that. If that method returns something that evaluates to false the do_authentication method will also call admin_user. Also looking at your code it seems that the admin authorization won't work also ...
try this:
def do_authentication
#post = Post.find_by_id(params[:id])
redirect_to redirect_location unless current_user.admin? or #post.user == current_user
end
def redirect_location
return "redirect_location_for_admin" if current_user.admin?
return "redirect_location_for_non_admins"
end
The methods correct_user,admin_user will be executed for all the users regardless of their role because you have not checked any condition while calling the methods.The code need to be improved to solve your problem.
def do_authentication
if current_user.admin?
#post = Post.find_by_id(params[:id])
else
#post = current_user.posts.find_by_id(params[:id])
redirect_to user_path(current_user), :notice => "Access denied" unless #post
end
end