API per verifiche prima e dopo Guardian

Qualcosa che ho riscontrato alcune volte durante la creazione di plugin è la necessità di modificare l’esito dei controlli can_* di Guardian. L’ho riscontrato di nuovo nel plugin ActivityPub:

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

Ho appena sollevato una bozza di PR che aggiunge un nuovo metodo API lato server che consente di registrare controlli prima e dopo i metodi can_* di guardian, offrendo la possibilità di modificare l’esito del metodo. Ad esempio:

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

Sono curioso di ricevere feedback sia sull’approccio che sull’esecuzione prima di pubblicarlo per la revisione.

7 Mi Piace

Sto solo riportando questo in alto per chiunque sia pertinente. cc @pmusaraj

1 Mi Piace

Grazie, Angus!

Non vedo problemi con la registrazione before_*. La registrazione after_* è un po’ più complicata. Dal punto di vista della sicurezza, la registrazione after_* significa che i plugin possono sovrascrivere il core in modi che potrebbero essere non sicuri. Ovviamente i plugin possono farlo in molti modi, ma l’API dei plugin non dovrebbe facilitarlo ulteriormente.

Inoltre, cosa succede se più plugin consumano l’hook after_*? Quale vince?

Sì, capisco cosa intendi.

I controlli accettano un argomento di priorità. Vedi questa specifica

it "rispetta la priorità del controllo" 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

Che ne dici se limito questo PR solo ai controlli before? Ciò soddisferebbe le esigenze immediate e ridurrebbe un po’ le variabili in gioco qui.

1 Mi Piace

Sì, certo, iniziamo solo con i controlli before. Grazie!