Open Justin-Maxwell opened 7 years ago
Hmm, that does sound like something that would be nice to have, and might be necessary for complex applications that have all sorts of strange domain rules.
This sounds like a case where authorizing based on the incoming parameters could help. See https://github.com/venuu/jsonapi-authorization/issues/33 for this. The key takeaway from my comment is this:
We might support this use case of deciding which parameters can be updated using policies in the future, like Pundit does with its
permitted_attributes
method, but it isn't happening any time soon.
We're aiming at supporting proper relationship authorization in jsonapi-authorization
version 1.0, and might be looking at supporting authorization for incoming parameters in the future.
Second this, I was just looking for a way to authorize the creation of a resource only when a related resource is present (i.e. submitted with the request) – and restrict the creation when no related resource was given. Am I correct that this is currently not possible, or is there a workaround?
Not possible with built-in jsonapi-authorization
It would be nice to be able to enforce in the policy that a POST must have a related resource specified.
Currently, via related_models_with_context, only related resources that are specified in the API data are mapped to createwith policies. And I can see the sense in that, and it might be 'weird' to check policies for nil relations; and of course, the model validations will kick in and reject the .create ...
But conceptually, it kinda feels right that
article.present?
belongs in theComment create_with_article?(associated_article)
policy. Rarely, there may be examples of resources where one class of user must specify a second resource to associate, to create the primary resource; but another class of user need not.I haven't really thought about whether the same thinking extends to the other
prefix_#{resource.name}
policy methods also, but on initial instincts I think it might only really be helpful for create, and I can't really see any harm from invoking all the createwith methods for a resource on creation if they are defined?