Filters authorization

[arcreative]

We have several situations where we would like to provide filter functionality, but only for certain users, e.g. admins. We're currently doing this by implementing a custom filter in JR and raising an invalid filter error if they're not allowed to use it based on the current context. It would be great, and seemingly more appropriate, if we could reject this based on our policy, probably as a pundit method that has access to the context.

And while we're at it, maybe this is a decent place to implement fetchable/creatable/updatable attributes as well, since this is more of a policy concern than a resource concern?

[valscion]

Seems like a feature that would allow validating incoming parameters somehow (be it fields to update or filters that are allowed to be used) could be useful.

Some previous issues that have been partially about this case: #33, #39, #68, #86

I would be interested to see how it would look like from the end result point of view — what policies would be called and with what parameters? Will we be able to do this kind of feature following the core principle of jsonapi-authorization: "Prefer being overly restrictive rather than too permissive by accident."

Even better if this could be implemented in a different gem that would merely tie into jsonapi-authorization. This way we would not have to worry about maintenance burden on this new code, as we already have limited time to do maintenance.

[arcreative]

Sounds reasonable. A couple of use cases we're currently needing this for / implementing via resources:

• An overall system admin should be able to filter on other admins (we call this filter has_elevated_access), but normal users should not
• A regional admin should be able to filter on certain attributes, say, performance-based metrics that are otherwise unavailable to normal users

I would imagine the filters access could, for the current version, allow all filters by default, but there could be either an allowed_filters method on the policy that could optionally be implemented, or alternatively, filter_on_has_elevated_access? (filter_on_<filter_name>?) that would be true by default, or optionally return false depending on the context. For future major versions, it could reasonably prevent filters by default, but I'm not sure that I feel this feature should be restrictive by default. I think "all filters for everyone" is the most common use case, but "all actions for everyone" is not.

[valscion]

I think preventing filters (and maybe even fields/attributes) by default could be a good option -- if developers would use this feature. That way it's either "no new restrictions" or an allowlist