Guardian の前後チェック api

開発
1

プラグインを構築していると、Guardian の can_* チェックの結果を変更する必要があることが何度かありました。ActivityPub プラグインでも再び見かけました。

https://github.com/discourse/discourse-activity-pub/blob/main/extensions/discourse_activity_pub_guardian_extension.rb

Guardian の can_* メソッドのチェックの前後を登録できるようにする新しいサーバーサイドプラグイン API メソッドを追加するドラフト PR を作成しました。これにより、メソッドの結果を変更できます。たとえば、

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

レビューのために公開する前に、アプローチと実行の両方についてフィードバックをいただけると幸いです。

「いいね！」 7
2

関連する方のために、この件を再度引き上げます。 @pmusaraj さん、ご確認ください。

「いいね！」 1
3

アンガス、ありがとう！

before_* レジスタに問題は見られません。after_* レジスタは少し厄介です。セキュリティの観点から、after_* レジスタは、プラグインが安全でない方法でコアを上書きできることを意味します。明らかにプラグインはあらゆる方法でこれを行うことができますが、プラグイン API はそれをさらに促進すべきではありません。

また、複数のプラグインが after_* フックを消費した場合、何が起こるのでしょうか？どちらが勝ちますか？

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 チェックのみに限定するのはどうでしょうか？それは当面のニーズを満たし、関係する変数を少し減らすことができます。

「いいね！」 1
5

はい、承知いたしました。まずは before チェックから始めましょう。ありがとうございます！