# Guardian before and after checks api
**URL:** https://meta.discourse.org/t/guardian-before-and-after-checks-api/307241
**Category:** Development
**Created:** [May 8, 2024, 11:53am UTC](https://meta.discourse.org/t/guardian-before-and-after-checks-api/307241 "2024-05-08T11:53:23Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [May 8, 2024, 11:53am UTC](https://meta.discourse.org/t/guardian-before-and-after-checks-api/307241/1 "2024-05-08T11:53:23Z")
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:
[https://github.com/discourse/discourse-activity-pub/blob/main/extensions/discourse\_activity\_pub\_guardian\_extension.rb](https://github.com/discourse/discourse-activity-pub/blob/main/extensions/discourse_activity_pub_guardian_extension.rb)
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
```ruby
add_guardian_check(:before, :edit_post) do |guardian, result, post|
!post.activity_pub_remote?
end
```
[https://github.com/discourse/discourse/pull/26936](https://github.com/discourse/discourse/pull/26936)
Curious to get feedback on both the approach and the execution before publishing it for review.
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [July 8, 2024, 6:36am UTC](https://meta.discourse.org/t/guardian-before-and-after-checks-api/307241/2 "2024-07-08T06:36:21Z")
Just bumping this one back up for whomever is relevant. cc @pmusaraj
---
### Author:  [@pmusaraj](https://meta.discourse.org/u/pmusaraj)
#### Post date: [July 26, 2024, 5:27pm UTC](https://meta.discourse.org/t/guardian-before-and-after-checks-api/307241/3 "2024-07-26T17:27:04Z")
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?
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [July 29, 2024, 8:02am UTC](https://meta.discourse.org/t/guardian-before-and-after-checks-api/307241/4 "2024-07-29T08:02:46Z")
> [@pmusaraj](#):
>
> 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.
Yeah, I understand what you mean.
> [@pmusaraj](#):
>
> Also, what happens if multiple plugins consume the `after_*` hook? Which one wins?
The checks accept a priority argument. See this spec
```plaintext
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.
---
### Author:  [@pmusaraj](https://meta.discourse.org/u/pmusaraj)
#### Post date: [July 29, 2024, 2:20pm UTC](https://meta.discourse.org/t/guardian-before-and-after-checks-api/307241/5 "2024-07-29T14:20:03Z")
Yes, sure, let’s start with just the `before` checks. Thanks!