Posto appropriato per proporre un predicato di permessi?

Sviluppatore
1

Nell’interesse di proporre una soluzione per Restrict exposure of full name to certain groups, vorrei definire un predicato di permessi (lato server) che risponda alla domanda

In base all’ambito/contesto dell’utente corrente, è corretto rivelare i nomi completi degli (altri) utenti?

(L’ambito potrebbe essere impostato da una richiesta del client o da una fase di elaborazione interna, come la generazione di messaggi e-mail digest.)

Qual è la costruzione giusta per un tale predicato? Dove nel codebase dovrebbe risiedere? Sto pensando che forse questo appartiene a un guardian — sono sulla strada giusta? Qualche opinione su quale?

Immagino che questo nuovo predicato ingloberebbe molte (ma non tutte) le istanze di SiteSettings.enable_names? attualmente nel codebase. (Colpire i Serializer che producono user.name tappa la maggior parte delle fughe di dati, ma non tutte.) Un bel vantaggio di questo è che introdurrebbe un punto di estensione per cui un futuro plugin potrebbe cambiare il comportamento (attualmente non possibile, per quanto ne so, o lo farei semplicemente!). Quindi, se riesco a far funzionare questo, questo diventerebbe una pull-request al core di discourse — e vorrei inviare una PR che abbia la speranza di essere accettata.

1 Mi Piace
2

Ecco cosa ho imparato/dedotto:

  • Guardian è effettivamente ciò che racchiude “Cosa è permesso fare all’utente?” (Un’istanza di Guardian ha anche un’istanza di User.)
  • Pertanto, il posto giusto per un predicato di permessi è semplicemente come metodo su Guardian (lib/guardian.rb).
    • Se il metodo è un “L’utente può fare Z a un oggetto Xxxx?” allora probabilmente appartiene a uno dei file di mixin XxxxGuardian (lib/guardian/...).
    • Altrimenti, va nella definizione di base di Guardian.
  • ApplicationController gestisce un attributo guardian che riflette la richiesta/client corrente e lo fornisce ai serializer come loro scope, quindi il Guardian corrente è disponibile quando necessario (tranne quando non lo è[1])
  • Ci sono posti in cui un Guardian pronto all’uso non è disponibile, tipicamente in un’attività di backend eseguita dal sistema, ma se hai in mano un “utente agente” (ad esempio, l’utente destinatario, quando si genera una notifica via email), puoi creare un guardian appropriato al volo: Guardian.new(the_user).

  1. ↩︎