Hopefully a simple one where I’m just not understanding the documentation properly between policies and AshJsonAPI.
I have a resource with two attributes where we use one of the attributes to reference a value that is held in our Actor struct. Note our “user” isn’t captured as a resource in Ash and we’re instead ad-hoc creating the Actor struct in a plug further up the pipeline.
This resource is exposed via AshJsonAPI and I’d like to put some access restrictions on the :create, :update, and :destroy actions where clients shouldn’t be allowed to create, update, or destroy records that they don’t “own”.
policy action_type([:update, :destroy]) do
forbid_unless expr(owner_id == ^actor(:name))
end
This seemingly works, however it returns a 404 instead of a 403 when a policy isn’t allowed for :update and :destroy. I’m not sure if that’s expected or not, but I thought :update and :destroy would yield the forbidden error rather than the “filtering” 404. Further, if I update the :access_type to force :strict mode then the policy never authorizes anything even when the exprshould be returning true (this one definitely confuses me). For a little more context the :read action is unrestricted so anyone can see anyone else’s records – they’re just not allowed to update/delete them.
policy action_type([:update, :destroy]) do
access_type :strict
authorize_if expr(owner == ^actor(:name))
end
Trying to figure out if I’m missing something, if the above behavior is an actual bug, or maybe I’m playing way out in left field somewhere.
There are actually two “modes” for authorizing bulk updates and destroys. AshJsonApi uses Ash.bulk_update and Ash.bulk_destroy with a filter for a single record as a mechanism for potentially avoiding the need to update the underlying record. It is currently using the default behavior, which adds the authorization rules for the update as a filter. We could make this configurable, telling AshJsonApi to pass authorize_changeset_with: :error (this is not supported by all data layers, but postgres can do it). This would give you the behavior you are looking for. Please open a proposal issue or PR . We can likely add a domain-wide and/or global configuration to start, which would be pretty straightforward.
access_type :strict
As to why access_type :strict doesn’t behave as expected, what access_type :strict means is that “everything in this policy must pass before ever attempting to speak to the data layer”. its effectively impossible to use a filter check in that context. You could instead write custom checks that do things like look at the changeset and compare changing values to the actor etc.
Thanks that’s super helpful, I’ll take a stab at opening that issue.
On creating the custom / simple checks to do the compares I ran into a related issue which is how I wound back up at expr in the first place. I noticed that a SimpleCheck for the :update and :destroy was always “missing” the data and instead had placeholder in it with a reference to the action being done atomically. Unlike with a Notifier I wasn’t seeing a way to get access to what was actually being updated/deleted to be able to use for comparison. I’m new to the forums so if this is better suited as a different topic let me know and I’ll open a different thread for better indexing.
Should I just not write a SimpleCheck and instead write the more involved Check or is there something I can tweak on the actions themselves to make the data available?
Thank you for taking the time by the way, Ash has been an awesome boost to development. One of those things where you start using it and you go, “Wait, isn’t this how it should’ve always been?”. Thanks again.
. We can likely add a domain-wide and/or global configuration to start, which would be pretty straightforward.
