zachdaniel:

A new builtin check has been added to help with resources where their authorization is generally dependent on some “parent” or related resource. For example, if you want anyone who can see a post to be able to see all of that posts comments, you could add a policy like this to comment:

bypass [accessing_from(Post, :comments), action_type(:read)] do
  authorize_if always()
end

This type of check also serves as an optimization to prevent the internals from needing to add filters to the underlying query. If you are loading comments through posts, we know that you can see all of them that are returned, so no need to filter the query for comments.

This is in main, but before you all dive in, know that main has a couple bugs in it that need to be fixed still 🙂

zachdaniel:

New builtin check: accessing_from

frankdugan3:

Very nice. Pretty sure I’ll be using it soon.

jharton:

Definitely something that <@740020573601792030>, <@248697708473352193> and I will be using as soon as it’s released.

_ahey:

I’ll be making good use of this! 😄

seven_seacat:

(better late than never but I’m using it now!)

_ahey:

This is such a nice feature. Some of my policies are complex, and involve filters across many joins which can be slow. I like to be able to query my resources directly via Graphql, and so I keep these policies around.

The nice part is that I can add an accessing_from bypass before these policies, so that when querying the resource as a subfield of another resource, the policy is bypassed, speeding up my requests nicely.

Eduardo B. Alexandre:

<@197905764424089601> Is the information from accessing_from somehow also accessible inside changes and validations? I have actions that call other actions, and these actions do a lot of checks inside changes, etc.

Some of these checks are the same in both actions, meaning that I checking the same thing twice, it would be great if I could check if that action was accessed from some other specific action and just bypass the change if that is the case.

Also, I belive this is true, but just to double check, I can also use these policies to block some action to be directly called right? I do have some actions that are meant only to be called by some other actions, never directly, so it would be great if I could use accessing_from to do a check and block that.

zachdaniel:

Yes, you can do that 🙂

zachdaniel:

The accessing_from is currently in private context I believe

zachdaniel:

but…you could use it.

Eduardo B. Alexandre:

<@197905764424089601> After reading more about this feature, it seems to be more specific to only relationships right? For example, I can have some specific policy when Ash uses the primary :read action to access some relationship of some other resource.

Can we have something similar but for actions intead of relationships?

For example, let’s say I have some action in resource A that I manually call inside a change block inside an action in resource B. It would be great if I could create some policy specifically for when that action is called from that resource.

That way I could do something like this:

policy action(:some_other_action) do
  forbid_unless accessing_from_action(ResourceB, :my_action)
end

In other words, with something like that I would be able to create a policy for an action to force it to only be usable internally by another resource action.

zachdaniel:

If you use manage_relationship we set the accessing_from context

zachdaniel:

Otherwise, you can probably set that context on the changeset manually

Eduardo B. Alexandre:

Will that work for generic actions as-well?

zachdaniel:

Umm…no

zachdaniel:

Actually maybe?

zachdaniel:

You’ll have to try it out 🙂