In my application_controller.rb I have the following line
rescue_from Pundit::NotAuthorizedError, with: :user_not_authorized
Now, in one method, I would like to handle that specific error differently and I've added this to one method in a controller.
class MyClass < ApplicationController
def my_method
# raising the Pundit::NotAuthorizedError in the method
authorize resource, :my_method?
rescue Pundit::NotAuthorizedError
# code on how to deal with the error
end
end
If I execute the code, the error handler from application_controller.rb will be handling my error instead of the error handler in the method.
So my question is, what is the precedence of the error handlers and is there any way I can change this, so that the error is handled in the method and not globally?
Please forget my previous answer, I myself made a mistake when reproducing your issue. In deed I am not able to reproduce it.
Please have a look at this little demo app I created:
https://github.com/andi-dev/rescue-handler-demo/blob/master/app/controllers/peas_controller.rb
The rescue_from handler is not executed, and the browser shows what I render from the rescue block within the action-method.
Related
I want to use rescue_from method on a model concern but neither exception error is rescued to the method i specified:
require "active_support/concern"
module CustomErrorHandler
extend ActiveSupport::Concern
include ActiveSupport::Rescuable
included do
rescue_from StandardError, with: :capture_error
end
private
def capture_error(e)
puts "Error catched!"
end
end
class FooClass
include CustomErrorHandler
def some_action
raise StandardError, 'Error'
end
end
err = FooClass.new
err.some_action
Traceback (most recent call last):
2: from (irb):28
1: from (irb):23:in `some_action'
StandardError (Error) # Didn't catch the error!
Anyone can help me on how can i solve this? Thanks!
This idea is fundamentially broken.
rescue_from is basically just syntactic sugar for:
class ThingsController < ApplicationController
around_action :wrap_in_a_rescue
def show
raise SomeKindOfException
end
private
def wrap_in_a_rescue
begin
yield
rescue SomeKindOfException
do_something_else
end
end
def do_something_else
render plain: 'Oh Noes!'
end
end
It only works because the controller declares a callback.
Its use makes sense in a controller as it rescues exceptions that occur in its callbacks as well as in the method itself and can be used with inheritiance to customize the error responses. It use does not make very much sense outside of that context.
While you could maybe fix this code by including ActiveSupport::Callbacks and declaring the requisite callbacks it is most likely a very overcomplicated solution to the original problem which can most likely be handled with a simple rescue or composition.
Let's say I have a rescue code on my application controller for handling access denied from cancan, like this:
class ApplicationController < ActionController::Base
rescue_from CanCan::AccessDenied do |exception|
#handle the exception
end
end
What I would like to do is, when the exception is raised, to show a popup to the user. But for that I should run a javascript code. How could I achieve that? Thanks in advance!
I'm pretty new to Rails and back-end API developement so excuse me if I misuse a concept or so. Right now I'm attempting to refactor a large amount of conditional error handling code that is sprinkled around the code base and move towards using an explicit list of rescued exceptions that's mixed into the API controller by including it in as a module. This will allow me to attach custom, but arbitrary, codes to each exception caught, so long as we use the bang alternatives for active record methods, and the error handling code can live in one place. So far, for the error handling module, I have something like this:
# app/lib/error/error_handling.rb
module Error
module ErrorHandling
def self.included(klass)
klass.class_eval do
rescue_from ActiveRecord::RecordNotFound do |e|
respond(:record_not_found, 404, e.to_s)
end
rescue_from ActiveRecord::ActiveRecordError do |e|
respond(e.error, 422, e.to_s)
end
rescue_from ActiveController::ParameterMissing do |e|
response(:unprocessable_entitry, 422, e.to_s)
end
rescue_from ActiveModel::ValidationError do |e|
response(e.error, 422, e.to_s)
end
rescue_from CustomApiError do |e|
respond(e.error, e.status, e.message.to_s)
end
rescue_from CanCan::AccessDenied do
respond(:forbidden, 401, "current user isn't authorized for that")
end
rescue_from StandardError do |e|
respond(:standard_error, 500, e.to_s)
end
end
end
private
def respond(_error, _status, _message)
render "layouts/api/errors", status: _status
end
end
end
Where layouts/api/errors is a view built using jbuilder.
In the ApiController we have:
# app/controllers/api/api_controller.rb
module Api
class ApiController < ApplicationController
include Error::ErrorHandling
attr_reader :active_user
layout "api/application"
before_action :authenticate_by_token!
before_action :set_uuid_header
respond_to :json
protect_from_forgery with: :null_session
skip_before_action :verify_authenticity_token, if: :json_request?
private
...
end
Unfortunately this doesn't seem to work. Running tests shows that the private methods are not being loaded at all and are considered undefined!
To be more specific, here are the errors emitted:
uninitialized constant Error::ErrorHandling::ActiveController
and
undefined local variable or method `active_user' for Api::FooController
Where active_user is an attribute that is set inside of an instance variable by a method named set_active_user. Which is obviously not being called.
However the ErrorHandling module is being evaluated. How could this be? Am I namespacing incorrectly or something?
Thanks for reading.
The answer is broken down into two parts as I believe that there are two separate problems.
unitinalized constant error
The error
uninitialized constant Error::ErrorHandling::ActiveController
can be fixed by changing this
rescue_from ActiveController::ParameterMissing do |e|
response(:unprocessable_entitry, 422, e.to_s)
end
to this:
rescue_from ::ActiveController::ParameterMissing do |e|
response(:unprocessable_entitry, 422, e.to_s)
end
(adding :: in front of the ActiveController constant)
Constant lookup in ruby takes lexical nesting into account. As you reference the Constant within
module Error
module ErrorHandling
...
end
end
ruby will try to find the constant within this namespace if the constant is undefined before. Prepending :: will tell ruby to ignore the nesting on constant lookup.
undefined local method
The error
undefined local variable or method `active_user' for Api::FooController
is raised because some code is calling the instance method active_user on the class Api::FooController where it is not defined.
I know this is an old question but I was struggling with it but found the fix. To fix the issue of:
`undefined local variable or method `active_user' for Api::FooController`
You need to include extend ActiveSupport::Concern e.g.
module Error
module ErrorHandling
extend ActiveSupport::Concern
# rest of your code
end
end
My Rails 4 app uses RocketPants for its JSON API and Pundit for authorization.
I have code in my /app/controllers/api/v1/base_controller.rb file to handle errors from Pundit. Whenever a user isn't authorized to update a resource, Pundit throws a NotAuthorizedError exception and I rescue it with my user_not_authorized method:
class API::V1::BaseController < RocketPants::Base
include Pundit
version 1
rescue_from Pundit::NotAuthorizedError, with: :user_not_authorized
def user_not_authorized
error! :forbidden
end
end
When I call the error! method that RocketPants provides from my exception handler, I expect to get a JSON response like this:
{
"error": "forbidden",
"error_description": "The requested action was forbidden."
}
Instead, however, calling error! just immediately blows up the request:
Completed 500 Internal Server Error in 143ms
RocketPants::Forbidden - RocketPants::Forbidden:
rocket_pants (1.13.1) lib/rocket_pants/controller/error_handling.rb:44:in `error!'
app/controllers/api/v1/base_controller.rb:61:in `user_not_authorized'
Full stack trace here.
Why isn't the error! method doing what it should when called from my Pundit exception handler?
If I put error! :forbidden in the middle of my controller action, it works as expected.
For context, the controller that inherits from base_controller.rb and calls Pundit's authorize method looks like this:
class API::V1::MealsController < API::V1::BaseController
before_filter :find_entity
def create
meal = #entity.meals.build(meal_params)
authorize(#entity, :update?)
if meal.save
expose meal, status: :created
else
expose meal.errors, status: 422
end
end
end
Apparently raising exceptions in a rescue_from is a bad idea and according to the Rails docs, exceptions raised in a handler are not bubbled up:
Exceptions raised inside exception handlers are not propagated up.
Docs: http://api.rubyonrails.org/classes/ActiveSupport/Rescuable/ClassMethods.html
Instead of re-raising RocketPants' exception, I'm simply creating and returning the JSON error message myself:
def user_not_authorized
# error! :forbidden
head 403
error = { error: 'Action not allowed.', error_description: 'Sorry, you are not allowed to perform this action.'}
expose error
end
This works!
UPDATE
I've since found an even cleaner solution: just map the Pundit exception to the RocketPants exception. This means that whenever a Pundit::NotAuthorizedError error is raised it'll be treated as a RocketPants::Forbidden error.
Got the entire solution down to a single line of code at the top of base_controller.rb:
map_error! Pundit::NotAuthorizedError, RocketPants::Forbidden
No handler required.
could someone explain the code in catch_exceptions?
i have difficulties to understand.
thanks
class ApplicationController < ActionController::Base
around_filter :catch_exceptions
private
def catch_exceptions
yield
rescue => exception
logger.debug "Caught exception! #{exception}"
raise
end
end
Simple.
You need first to understand the concept of the around_filter. It puts something AROUND a method call. Also you need to understand YIELD, that is executing a block.
so if you have something like an Index action.
def index
# run code run
end
that means it will be sent as a block to that around_filter, which will execute that just as if it were...
def catch_exceptions
def index
#run code run
end
rescue => exception
logger.debug "Caught exception! #{exception}"
raise
end
catch_exceptions is a method that takes a block. You can tell because it contains a yield (which executes the passed in block).
The method is catching any exception that occurs in that block, logging them, then re-throwing them so other code can catch it too.
The 'around_filter' line makes rails pass each controller method that would be executed to the catch_exceptions method instead.
The overall result is that all exceptions thrown by controller methods get logged.