angus
5월 8, 2024, 11:53오전
1
플러그인을 만들 때 몇 번이나 마주친 일이 있는데, Guardian의 can_* 체크 결과를 수정해야 하는 경우가 있습니다. ActivityPub 플러그인에서도 다시 이 문제를 마주쳤습니다:
https://github.com/discourse/discourse-activity-pub/blob/main/extensions/discourse_activity_pub_guardian_extension.rb
방금, 가디언의 can_* 메서드에 대한 before/after 체크를 등록할 수 있는 새로운 서버 측 플러그인 API 메서드를 추가하는 초안 PR을 올렸습니다. 이를 통해 해당 메서드의 결과를 변경할 수 있습니다. 예를 들어:
add_guardian_check(:before, :edit_post) do |guardian, result, post|
!post.activity_pub_remote?
end
main ← angusmcleod:add_plugin_api_to_guardian
closed 01:55AM - 21 Sep 24 UTC
Adds a system to allow plugins to more easily modify guardian `can_` method outc… omes.
### Example
Currently the only way to modify guardian `can_` method outcomes is via module pre-pension, for example:
```
module DiscourseActivityPubGuardianExtension
def can_edit_post?(post)
return false if post.activity_pub_remote?
super
end
def can_change_post_owner?
return false if activity_pub_enabled_topic?
super
end
def activity_pub_enabled_topic?
return false unless DiscourseActivityPub.enabled && request&.params&.[]("topic_id")
topic = Topic.find_by(id: request.params["topic_id"].to_i)
topic&.activity_pub_enabled
end
end
...
Guardian.prepend DiscourseActivityPubGuardianExtension
```
[See further](https://github.com/discourse/discourse-activity-pub/blob/main/extensions/discourse_activity_pub_guardian_extension.rb)
This change would mean the above could be done via the plugin api like so:
```
add_guardian_check(:before, :edit_post) do |guardian, result, post|
!post.activity_pub_remote?
end
add_guardian_check(:before, :change_post_owner) do |guardian|
return true unless DiscourseActivityPub.enabled && guardian.request&.params&.[]("topic_id")
topic = Topic.find_by(id: guardian.request.params["topic_id"].to_i)
!topic&.activity_pub_enabled
end
```
리뷰를 위해 공개하기 전에 접근 방식과 구현 모두에 대한 피드백을 듣고 싶습니다.
angus
7월 8, 2024, 6:36오전
2
관련 있는 분들을 위해 이 이슈를 다시 올려봅니다. @pmusaraj 참조
pmusaraj
7월 26, 2024, 5:27오후
3
감사합니다, Angus!
before_* 레지스터에는 문제가 없어 보입니다. after_* 레지스터는 조금 더 까다롭습니다. 보안 측면에서 after_* 레지스터는 플러그인이 코어를 비안전한 방식으로 오버라이드할 수 있게 만듭니다. 물론 플러그인은 다양한 방법으로 이런 일을 할 수 있지만, 플러그인 API가 이를 더 촉진해서는 안 됩니다.
또한, 여러 플러그인이 after_* 훅을 소비하면 어떻게 되나요? 어느 쪽이 우선순위를 갖게 되나요?
angus
7월 29, 2024, 8:02오전
4
네, 말씀하시는 뜻을 이해합니다.
체크는 우선순위 인수를 허용합니다. 이 스펙을 참고해 보세요.
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
이 PR을 before 체크로만 제한하는 건 어떨까요? 그러면 즉각적인 요구사항을 충족하면서도 여기에서 변수를 조금 줄일 수 있을 것입니다.
pmusaraj
7월 29, 2024, 2:20오후
5
네, 물론이죠. before 체크부터 시작해 보겠습니다. 감사합니다!