Sistema de Administradores y Moderadores

[fagiannoni]

¿Qué se implementa?

• Manejo de roles con admin y mods (PAN-19).
• Un usuario hardcodeado en el .env será admin. *Nota sobre esto al final.
• El admin puede ver la lista de mods vigentes (GET), agregar mods (POST) o eliminar mods (DELETE) a través del endpoint /auth/mod (PAN-162).
• Función para requerir acceso de mod (require_mod_auth) o admin (require_admin_auth) para ciertas rutas (e.g. /sync requiere permisos de admin PAN-161).
• Endpoints para checkear autorización de accesos admin (GET /auth/check/admin) y mod (GET /auth/check/mod).

¿Qué falta?

• En el PAN-19 se propone reconocer el rol de invitado, pero creo que esto se debería implementar en otra rama. Pensaba agregar simplemente agregar otra clase key como GuestKey para entregar ciertos permisos limitados a este tipo de usuario. Aunque igual pueden haber otras formas de proceder con la implementación así que prefiero dejar esto aquí para discutirlo.
• Trackear JWTs emitidos a moderadores con el fin de poder revocar su acceso de forma instantánea, incluso antes de que el token expire. No creo que sea prioritario (quedó anotado como TODO).

Detalle de la implementación

• Nuevo modelo AccessLevel en la base de datos que relaciona user_ruts a un atributo is_mod. Actualmente todos los registros de dicha tabla deberían tener is_mod=True y ser removidos en caso contrario, pero a futuro podría agregarse is_admin si se quiere tener la opción de múltiples admins (*como se comenta abajo en la nota).
• Clases UserKey, ModKey(UserKey) y AdminKey(ModKey) para generar permisos de autorización. Notar que por herencia todo admin es mod, y todo mod es usuario.

Notas sobre la implementación

• La idea propuesta en Linear conlleva poder tener múltiples admins, donde estos pueden dar/quitar accesos de admin. Decidí optar por otra vía (aunque la mayoría del código funciona para cualquier caso por lo que debería ser fácil cambiarlo) donde solamente existe 1 admin y puede entregar/quitar accesos de mod pero no admin. El RUT del admin estará hardcodeado en una variable de entorno directamente en la máquina. Pensé en los casos de uso y consideré que esta era la mejor forma de hacerlo, pero obviamente se puede extender todavía a la idea original de varios admins.

[linear]

PAN-162 El administrador puede cambiar la lista de administradores y moderadores

PAN-161 Solo permitir a los administradores sincronizar la base de datos con fuentes externas

PAN-19 Manejo de roles

El sistema debe reconocer los distintos roles del sistema (invitado, usuario, moderador y administrador) y debe haber una forma establecida para revisar el rol desde las rutas del back.

[kovaxis]

Genial! Voy a revisarlo.

Respecto al GuestKey, no creo que sea necesario. Los invitados no necesitan autenticacion, por lo que me seria raro agregar algun tipo de GuestKey. Los endpoints que sean accesibles a invitados simplemente no debieran requerir ninguna key.

[kovaxis]

Me parece excelente, mergeable 👍 .

Respecto a hardcodear un admin en el .env, lo veo bien. Justo habia pensado en algo asi jasjdfjasj. Simplifica bien las cosas.

[kovaxis]

Respecto a revocar permisos antes que expiren los tokens, seria una buena mejora, pero estoy de acuerdo que no nos preocupemos tanto por ahora.

Si lo implementamos en algun momento, mas que trackear los tokens y revocarlos, no guardaria ninguna informacion de admin en el token mismo, y en vez buscaria en la tabla AccessLevel al decodear el token.