Does FilterCheck also raise an error?

  policies do
    policy action_type(:read) do
      forbid_if expr(type(true, :boolean))
      authorize_if always()
    end
  end

I think forbid_if expr(type(true, :boolean)) is an inline filter policy,
so Ash.read!(ResourceModule) should return [],
but it raises an error.

** (Ash.Error.Forbidden) Forbidden Error

* forbidden
  (elixir 1.17.0) lib/process.ex:864: Process.info/2
  (ash 3.4.1) lib/ash/error/forbidden/policy.ex:9: Ash.Error.Forbidden.Policy."exception (overridable 2)"/1
  (ash 3.4.1) lib/ash/error/forbidden/policy.ex:28: Ash.Error.Forbidden.Policy.exception/1
  (ash 3.4.1) lib/ash/policy/authorizer/authorizer.ex:1529: Ash.Policy.Authorizer.strict_check_result/2
  (ash 3.4.1) lib/ash/policy/authorizer/authorizer.ex:617: Ash.Policy.Authorizer.strict_check/2
  (ash 3.4.1) lib/ash/can.ex:412: anonymous fn/6 in Ash.Can.run_check/4
  (elixir 1.17.0) lib/enum.ex:4858: Enumerable.List.reduce/3
  (elixir 1.17.0) lib/enum.ex:2585: Enum.reduce_while/3
  (ash 3.4.1) lib/ash/can.ex:409: Ash.Can.run_check/4
  (ash 3.4.1) lib/ash/can.ex:118: Ash.Can.can/4
  (ash 3.4.1) lib/ash.ex:1283: Ash.can/3
  (ash 3.4.1) lib/ash/actions/read/read.ex:1163: Ash.Actions.Read.authorize_query/2
  (ash 3.4.1) lib/ash/actions/read/read.ex:365: Ash.Actions.Read.do_read/4
  (ash 3.4.1) lib/ash/actions/read/read.ex:249: Ash.Actions.Read.do_run/3
  (ash 3.4.1) lib/ash/actions/read/read.ex:66: anonymous fn/3 in Ash.Actions.Read.run/3
  (ash 3.4.1) lib/ash/actions/read/read.ex:65: Ash.Actions.Read.run/3
  (ash 3.4.1) lib/ash.ex:1887: Ash.read/2
  (ash 3.4.1) lib/ash.ex:1846: Ash.read!/2
  (elixir 1.17.0) src/elixir.erl:386: :elixir.eval_external_handler/3
  (stdlib 6.0) erl_eval.erl:904: :erl_eval.do_apply/7
    (elixir 1.17.0) lib/process.ex:864: Process.info/2
    (ash 3.4.1) lib/ash/error/forbidden.ex:3: Ash.Error.Forbidden.exception/1
    (ash 3.4.1) /Users/r4f3works/fireworks/r3world/deps/splode/lib/splode.ex:211: Ash.Error.to_class/2
    (ash 3.4.1) lib/ash/error/error.ex:66: Ash.Error.to_error_class/2
    (ash 3.4.1) lib/ash/actions/read/read.ex:340: anonymous fn/3 in Ash.Actions.Read.do_run/3
    (ash 3.4.1) lib/ash/actions/read/read.ex:265: Ash.Actions.Read.do_run/3
    (ash 3.4.1) lib/ash/actions/read/read.ex:66: anonymous fn/3 in Ash.Actions.Read.run/3
    (ash 3.4.1) lib/ash/actions/read/read.ex:65: Ash.Actions.Read.run/3
    (ash 3.4.1) lib/ash.ex:1887: Ash.read/2
    (ash 3.4.1) lib/ash.ex:1846: Ash.read!/2
    iex:6: (file)

Is this an intended behavior?

:thinking: The primary issue here is that we are statically determining that the policy fails. A filter check will still raise an error if policies are statically false.

i.e forbid_if true is immediately incorrect, no queries must be made.

But I think the behavior of FilterPolicy should be predictable.
In some cases, raise error and in other cases, query and filter confuses me.

If I write a complex inline FilterPolicy,
something like expr(<statically determinable clause> and <dynamically determinable clause> and ...)
then this could be so hard to predict the result. @zachdaniel

…yes. You’re right. I’ll look into it.

@rapidfsub I’ve pushed something up to main that should make this consistent with the only exception of

authorize_if expr(boolean)
# or
authorize_if boolean

which will still be a static failure.

Okay, so this is actually going to have to be opt-in behavior so as to be backwards compatible. On the new version of Ash, you’d say:

  config :ash, :policy, no_filter_static_forbidden_reads?: false

In the future (e.g. ash 4.0), this would be a default behaviour?

Yes, it would be :slight_smile:

Sorry for late feedback.
I was focused on other things.

Now I started to use config :ash, policies: [no_filter_static_forbidden_reads?: false].
And I found SimpleCheck also does not raise error in read action.

But I think only FilterCheck should not raise error,
and SimpleCheck “should” raise error.
If not, we can’t forbid read actions “at all”.

You can forbid read actions, the way you do it is by marking a policy as access_type :strict

Thanks. I should have read the updated policy docs.

1 Like