Permitting specific parameter values

[dgmora]

I have the following problem:
For some actions (like update?) certain users can update a field to some specific values, some other users cannot. Think of it as a condition like this:

   if post.published?
     # params[:post][:state] must be in 'draft'
   elsif post.published? && user.admin?
     # params[:post][:state] must be in 'draft', 'deleted'
   end

Rails does not provide such a mechanism to filter for specific values, and I think that pundit doesn't. This is quite complicated, but I can't work around this requirement. I was thinking to add some helper to my ApplicationPolicy like filtered_params(params) that would do this.

Should I try that? Should I keep it out of authorization? This makes policies a bit more complex, but the methods to check the current user permissions are in the policies, so I think it makes more sense. Should Pundit itself provide something like this?

[Burgestrand]

You're right, Pundit itself doesn't specifically guide you in how to deal with this fine-grainedness. It covers much more about who can do which verb to which resource.

The past few years at Varvet, we've been writing more and more specialised functions/services/commands. I don't know what the most descriptive term is, but it effectively maps the user's intent to a named action that fits within the business domain.

Without going too detailed, instead of having a single update action and altering the permitted_parameters based on authorization rules, we're creating multiple actions/resources (e.g. users/role#update, docks/opening_hours#update). This means each action can be much more granular in which parameters are accepted, and each authorization rule becomes more specific:

• Is a regular user allowed to PromoteUserToAdmin?
• Is a manager allowed to RemoveUserFromOrganisation?
• Is a dock inspector allowed to UpdateDockOpeningHours?

These actions tend to map to actions real users take, in the same manner we speak about these actions when talking to non-developers such as product owners or stakeholders.

I'm not saying this is the way to do it, but it's an alternative to inspecting the params and trying to figure out authorization rules for each combination.

[Burgestrand]

I should mention that the past 3ish years we've needed Pundit in a relatively light capacity, so I'm hesitant to recommend this approach through the README without having battle-tested it thoroughly first.

[Burgestrand]

Oh, I should also mention that historically Pundit decided to get involved with which values are getting assigned by having helpers for permitted_attributes, but decided to not concern itself with what those values contain, leaving that to be outside the scope of Pundit.

[dgmora]

Hello, thanks for the example! It helps to understand how others do it.

In some are we tried this approach, although in our case this involved certain complexity because from one same view like edit different users may be able to edit different attributes, or set different values (for instance, certain state transitions can only be done by certain users). In that case it isn't that practical to make more granular actions, but I think in others it could.

We ended up using a helper like this for such helpers:

class MyPolicy < ApplicationPolicy
  alias report resource

  filtered_param :state, only: %w[draft in_review], on: :update?, condition: :admin?

We haven't used this a lot and it's possible that it doesn't scale very well, but it helped in the cases where we needed it.