Question

I have two types of users: user and editor. I have a User model with the boolean column is_editor to determine if a user is an editor.

Let’s assume. User Foobar decides to sign up as an editor. He succeeds. From today onwards, he is an editor. One day Foobar accidentally navigates to the editor registration page (registrations controller, new action).

Since Foobar is already an Editor, I should redirect him to his profile page. Should I use an authorization gem (such as Cancan) for this? Or should I have a simple method (i.e. before_filter :check_if_user_is_not_an_editor) in the registrations controller that checks if user is already an editor and redirect?

If I end up using the Cancan approach. The thing is, I already have the following that checks for other authorization.

  rescue_from CanCan::AccessDenied do |exception|
    flash[:alert] = exception.message
    redirect_to root_url
  end

Which will render a flash alert message: You are not authorized and redirect to root url. Which is not what I want, because I need to redirect to Foobar’s profile instead.

What are your thoughts? Is this the task of authorization or just a simple redirect in the said controller? Which is the more appropriate approach?

Answer 1

Honestly, it seems pretty minor so whatever you choose, I wouldn’t feel bad about your approach. Personally, I would go with your second option (simple redirect). First of all, it seems simpler, which is always a plus. If you’re using an authentication solution like Devise, you probably have a current_user or user_signed_in? helper that you can use in a before filter quite easily. Secondly, it doesn’t really strike me as the type of problem that authorization is concerned with.

In one sense, it is a permissions concern (I guess semantically anyways) since your application defines behavior that is ‘not allowed’. Realistically, it’s not allowed but not because the user doesn’t have necessary permission. The reason the behavior isn’t allowed is because no user should be able to register as the same type of user they’re already registered as – that is, there are no user types that should be able to do such a thing so the currently-logged in user’s permissions are moot. It seems like your problem should be resolved by defining application behavior – not user permissions.

Just the way I see things, feel free to implement whatever solution you feel fits best.