Rails Nested Controller Index Action Authorization

[cgmcintyr]

Reading through the documentation I can't figure out the recommended way to authorize a nested controller's index action when using rails. In particular my issue is passing information about the resources the controller is nested under to action_policy.

Example Description

To illustrate my problem, let's say I'm writing a holiday request system for HR.

There are normal users who can create requests, can view their own requests (RequestsController#index), and view their own profile page (UsersController#show), but cannot view any other user's requests or profile page.

There are also users with the "approver" role, who can view every user's requests and profile page.

For this example the UX flow for an approver approving a request would be:

Approver Logs In
	-> Visits User Index page
	-> Clicks on "requests" next to a user
	-> Gets taken to that user's Requests Index page
	-> Click on the "approve" button next to the top request

Example Code

As requests are owned by a user, they are a nested resource. So my config/routes.rb would include:

Rails.application.routes.draw do
  resources :users do
    resources :requests
  end
end

With the following policies defined under app/policies:

class UserPolicy < ApplicationPolicy
  default_rule :manage?

  def manage?
    return true if user.approver?
    user.id == record.id
  end
end

class RequestPolicy < ApplicationPolicy
  default_rule :manage?

  def manage?
    return true if user.approver?
    user.id == record.user.id
  end
end

Problem

At the moment I could authorize RequestsController#index using my UserPolicy

class RequestsController < ApplicationController
  def index
    @user = User.find(params[:user_id])
		
    # If you can view a user's profile, you can view their request page
    authorize! @user, to: :show?
		
    @requests = @user.requests.all
  end
end

But it feels like this is a policy decision that should be kept in RequestPolicy, with some way to pass an owner to the RequestPolicy#index:

class RequestPolicy < ApplicationPolicy
  default_rule :manage?
	
  def index
    allowed_to?(:show?, owner)
  end

  def manage?
    return true if user.approver?
    user.id == record.id
  end
end

Which could then be called like:

class RequestsController < ApplicationController
  def index
    @owner = User.find(params[:user_id])
    authorize!	
    @requests = @owner.requests.all
  end
end

I looked into using action_policy contexts, but the documentation states this is about adding extra context information about the subject, and in my case we are adding extra context about the resource (or maybe I've got this wrong and it is subject information?)

Is there a recommended way to solve this problem? Should I continue calling different policies from my controller code? Or is there a way to add extra data apart from the Request class when calling authorize! from a nested controller index action?

[palkan]

To my opinion, your original implementation (authorize! @user, to: :show?) is correct: whenever you deal with a nested resource and a collection action (like #index), you should authorize access to the current scope (parent resource). That's how I've been dealing with this problem for a long time (even before Action Policy).

However, I see a different (maybe, even better) way of handling this situation with Action Policy. We may consider a user to be the authorization context, why not? If we agree on this, we can then use optional authorization context in the policy:

class RequestPolicy < ApplicationPolicy
  authorize :owner, optional: true

  default_rule :manage?
	
  def index
    allowed_to?(:show?, owner)
  end
end

And then in your controller you write:

def index
  @owner = User.find(params[:user_id])
  # pass owner explicitly
  authorize! context: {owner: @owner}
  @requests = @owner.requests.all
end

[cgmcintyr]

Hi, thanks for your quick response!

I did reach for the second way initially. However, this section of the documentation stopped me from going with this approach:

Authorization context contains information about the acting subject

In most cases, it is just a user, but sometimes it could be a composition of subjects.

Maybe it could be updated to:

Authorization context contains all contextual information required to apply a policy rule.

In most cases, it only contains a user. However, if needed, Action Policy allows extending a policy's authorization context to include any additional information required to contextualize the authorization of a resource.

[palkan]

Done!

[cgmcintyr]

Sweet! Thanks for being so responsive, and thanks for all your work building such an awesome library :)

[brendon]

Just wanted to say I'm so glad I found this answer :) In my case I didn't need to make the parent context optional because it always exists when dealing with the child. That's ok isn't it?

I also set the context in the controller class itself instead of specially passing it in in that use case in index?.

[palkan]

I didn't need to make the parent context optional because it always exists when dealing with the child. That's ok isn't it?

Sure it is 🙂