Guardian before and after checks api

dev
1

Something I’ve come across a few times when building plugins is the need to modify the outcome of Guardian can_* checks. I’ve come across it again in the ActivityPub Plugin:

I’ve just raised a draft PR that adds a new server-side plugin api method that allows you to register before and after checks to guardian can_* methods, affording the ability to change the outcome of the method. For example

add_guardian_check(:before, :edit_post) do |guardian, result, post|
  !post.activity_pub_remote?
end

Curious to get feedback on both the approach and the execution before publishing it for review.

7 Likes
2

Just bumping this one back up for whomever is relevant. cc @pmusaraj

1 Like
3

Thanks, Angus!

I don’t see any issues with the before_* register. The after_* register is a little trickier. Security-wise, the after_* register means plugins can override core in ways that may be unsafe. Obviously plugins can do this in all sorts of ways, but the plugin API shouldn’t facilitate it even further.

Also, what happens if multiple plugins consume the after_* hook? Which one wins?

4

Yeah, I understand what you mean.

The checks accept a priority argument. See this spec

it "respects check priority" do
  plugin.add_guardian_check(:after, :edit_post, 2) { false }
  plugin.add_guardian_check(:after, :edit_post, 0) { true }
  plugin.add_guardian_check(:after, :edit_post, 1) { false }
  expect(Guardian.new(user).can_edit_post?(post)).to be_truthy
end

How about I limit this PR to just before checks? That would serve the immediate needs and reduce the variables in play a bit here.

1 Like
5

Yes, sure, let’s start with just the before checks. Thanks!