¿Lugar adecuado para proponer un predicado de permisos?

Desarrollador
1

Para proponer una solución para Restrict exposure of full name to certain groups, me gustaría definir un predicado de permisos (del lado del servidor) que responda a la pregunta:

Basado en el ámbito/contexto del usuario actual, ¿está bien revelar los nombres completos de (otros) usuarios?

(El ámbito podría establecerse mediante una solicitud del cliente o mediante algún paso de procesamiento interno, como la generación de mensajes de correo electrónico de resumen).

¿Cuál es la construcción correcta para dicho predicado? ¿Dónde debería vivir en la base de código? Estoy pensando que tal vez esto pertenezca a un guardián (guardian) — ¿voy por buen camino? ¿Alguna opinión sobre cuál?

Imagino que este nuevo predicado subsumiría muchas (pero no todas) las instancias de SiteSettings.enable_names? actualmente en la base de código. (Acceder a los Serializers que devuelven user.name tapa la mayoría de las fugas de datos, pero no todas). Un buen beneficio de esto es que introduciría un punto de extensión mediante el cual un plugin futuro podría cambiar el comportamiento (actualmente no es posible, hasta donde sé, ¡o simplemente lo haría!). Por lo tanto, si consigo que esto funcione, se convertiría en una solicitud de extracción (pull-request) al núcleo de Discourse — y me gustaría enviar una PR que tenga esperanzas de ser aceptada.

1 me gusta
2

Aquí está lo que he aprendido/deducido:

  • Guardian es, de hecho, lo que encapsula “¿Qué se le permite hacer al usuario?” (Una instancia de Guardian tiene una instancia de User, también).
  • Por lo tanto, el lugar adecuado para un predicado de permisos es simplemente como un método en Guardian (lib/guardian.rb).
    • Si el método es “¿Puede el usuario hacer Z a un objeto Xxxx?”, entonces probablemente pertenezca a uno de los archivos de mezcla XxxxGuardian (lib/guardian/...).
    • De lo contrario, va a la definición base de Guardian.
  • ApplicationController administra un atributo guardian que refleja la solicitud/cliente actual y lo proporciona a los serializadores como su scope, por lo que el Guardian actual está disponible cuando se necesita (excepto cuando no lo está[1]).
  • Hay lugares donde un Guardian listo para usar no está disponible, típicamente en una tarea de backend ejecutada por el sistema, pero si tienes un control sobre un “usuario actuante” (por ejemplo, el usuario destinatario, al generar una notificación por correo electrónico), puedes crear un guardián apropiado sobre la marcha: Guardian.new(the_user).

  1. ↩︎