Authorizing fields based on params_filter

[jclusso]

We're using params_filter and I was wondering how you're supposed to adjust your views based on it? For example, certain users can't input certain fields and I was wondering how you can see if they have access to that param from the view. I didn't see anything that clearly outlined this in the documentation.

[palkan]

Looks like you're looking for something we discussed here: #213

[jclusso]

I didn't realize there was a policy_for method. I realized it's mentioned once in the documentation now, but the fact that it won't work out of the box would make me not want to use it in fear that it might not work in the future. I ultimately just made a permission for the one field and used allowed_to?, but this isn't very scalable if you have a bunch of fields with more complex permissions. I do think it would be nice if there was a documented way to do this since I imagine anyone use params_filters would need to filter inputs.

For things to work the cleanest, I think params_filter would need to work differently. Currently it requires the params be passed to it, but instead I think it shouldn't need that. I suppose this would break anyone who relies on the params to filter the fields, but I can't imagine that's very secure anyway. If params_filter no longer was dependant on the params, it could then be easily used to make a method like permitted_params?(@record).

[palkan]

I think params_filter would need to work differently.

The #params_filter serves a different purpose—filtering incoming data according to authorization rules.

Building conditional views depending on authorization is a different task.

Frankly speaking, making policy classes know about input fields isn't a good idea, architecture-wise. Authorization policies shouldn't be coupled with the presentation; it should deal with subjects, objects and actions. Sure, we can say that we're not talking about views, but model attributes. That's fine. But then there should be some permissions-related behind showing or not showing a particular input (e.g., I can't see the "Admin" checkbox, because I cannot manage admins, i.e., allowed_to?(:manage, :admin).

Thus, adding a specific rule to the policy to reflect some tricky use-case (I think, as you did) is a way to go.

P.S. The .params_filter has the same problem. Ideally, input filtering should be handled by a separate abstraction, which uses policy rules to make decisions. However, that could make the whole architecture too complicated, especially for typical Rails projects. Maybe, we need some concept of a View Policy (which wraps the authorization policy and provides information related to a particular view).

[jclusso]

I will say I don't have an much knowledge about best practicies in authorization frameworks or how this "should" work. If I'm understanding you correctly, you'd say we should just define individual actions that control the fields by reusing those actions within the params_filter. I see your logic in this and agree. I am interested in this View Policy concept though.