Provide documentation on how to do nested resources.

[Blaž Hrastnik]

I have a nested resource as such:

resources "/companies", CompanyController, only: [:create, :index, :show, :update] do
  resources "/users", UserController, only: [:index]
end

I want the user to be able to view all of the users by the same company, but not any other company's users. The problem is, on a route like /companies/:id/users, the id parameter is ignored and not passed further.

Parameters: %{"company_id" => "e6cda375-72d8-4bd3-9437-112db20dc62e"}

defmodule App.User.Policy do
  # I can't really do validations here, because on index just the User module is passed in, with no other context.
  def can?(_user, :index, User), do: true
end

Should I separately be authorizing the company and then the user/index action? That means I'd have to separately load the company from the db... when in my case I could simply compare current_user.company_id == id

[Rockwell Schrock]

Should I separately be authorizing the company and then the user/index action?

In general, yes. Since this is a nested resource, you should probably be authorizing the parent resource in EVERY action of the child resource, regardless. This is easy to add as a controller plug.

If you're truly just checking the ID, create a struct %Company{id: params["company_id"]} in memory and authorize that directly. Then you don't need to hit the DB since you don't need the entire contents of the schema. If, later on, your authorization needs become more complex, then you can simply modify that plug to load the full Company schema from the DB.

In your particular case, one could argue that if the user is only ever accessing stuff about their current company, that there should be a /my_company route and MyCompany controller that assigns company_id as current_user.company.id, bypassing that authorization check since company_id is no longer user-supplied, and also being more semantic. Then you could also create a matching policy, like MyCompanyUsersPolicy, which would have the specific authorization logic as well as scope information for the index (i.e. only fetch users where their company_id matches current_user.company_id).