Authorizing create/update by context of the instance of the record class being updated?

[carlthuringer]

Hi, just digging into using Pundit and jsonapi-authorization on a fairly large project and ran into an issue with authorizing the create.

My create? method receives the Class, not the instance being created:
ChainSetting(id: integer, chain_id: integer, key: string, value: string, created_at: datetime, updated_at: datetime)

In this case, I have authorized a specific user account and within the tree of my models, I can traverse from that specific user down to a specific record of a chain, validating ownership of the chain.

So what I want to do is, given the user has made a create request to create a new ChainSetting with a chain_id: 1234, I want to lookup all the user's chains (I can do this, just join some rows) and validate that 1234 is in fact one of the user's chains.

But instead the model passed to the Policy is just the raw Class, not an instance! Awwugh!

I took a quick look through the source code and it seems the Processor is responsible for deciding what to send to the authorization policies. I'm about to check out for the day so I can't dive any deeper into it.

It seems to me that there's a flaw here. If API users are authorized to blindly create, then they can create relationships for each others' records, and we don't want that at all!

You may be noticing that I'm setting a foreign key like it's an attribute. Yes, that's strange, but not disallowed in json api. We have a convoluted legacy database here with foreign key constraints and hooks and callbacks galore that make some more orthodox updates difficult.

Regardless of this breach of protocol, one should be able to say that a Red User is authorized to update "ChainSetting" with door_color: red but not door_color: black, if that's what we want to do. In normal Pundit you can pass an instance and validate just like that, but in jsonapi-authorization it's not possible.

What are your thoughts? Shouldn't the instance being authorized be passed to the Policy?

[valscion]

You can check out DefaultPunditAuthorizer class to see how each operation is mapped to a Pundit policy check. As you found out, create gets the class and not the instance itself. However, we also restrict you from creating relationships to objects you don't have an update permission for, see the code.

We authorize actions at the edge of the API before any models are changed or objects are built. If you're looking for authorization on a before_save hook, you might find that pundit-resources suits you better.

Currently with jsonapi-authorization (JA), you cannot authorize for the incoming parameters. That's what issue #33 is about.

Right now JA is not capable of handling these complex cases that you have. We might have support for these in the future, but not yet.

[valscion]

Closing due to inactivity. Please feel free to comment on this if you have further questions or want this to be reopened ☺️

[nozpheratu]

How do you think something like this could be implemented? A smart before_action hook could probably make some logical assumptions based on the action being called assuming the user using a standard CRUD API.

[valscion]

No idea, I haven't thought this much yet.

[nozpheratu]

I'm doing something like this right now:

module V1
  class ResultsController < ApiController
    def create
      unless ResultPolicy.new(current_user, _result)._create?
        raise Pundit::NotAuthorizedError
      end
      super
    end

    def drestroy
      unless ResultPolicy.new(current_user, _result)._destroy?
        raise Pundit::NotAuthorizedError
      end
      super
    end

    def update
      unless ResultPolicy.new(current_user, _result)._create?
        raise Pundit::NotAuthorizedError
      end
      super
    end

    private

    def _result
      Result.new(params.require(:data).permit(:attributes))
    end
  end
end

It's not ideal, I can't just override the existing CRUD actions in my Policy class since I don't think there's a way for JA to skip them during it's normal authorization calls where it's passing the Class instead of the instance.

But I suppose it works well enough for me since the cases where the extra complex authorization rules are needed are rare.

[valscion]

I don't think there's a way for JA to skip them during it's normal authorization calls where it's passing the Class instead of the instance.

You can create your own authorizer class by subclassing from DefaultPunditAuthorizer and configure that class to do what you want to do. Just beware that upgrading to v1 will be a breaking change, but hopefully it wouldn't require too many changes :)

https://github.com/venuu/jsonapi-authorization#configuration

Check out the current implementation of the authorizer in v0.8.2: https://github.com/venuu/jsonapi-authorization/blob/v0.8.2/lib/jsonapi/authorization/default_pundit_authorizer.rb