Aplicado en la base de datos
Quién puede leer o cambiar una fila en Fóir lo decide Postgres. Las reglas se escriben una vez, en una sola especificación, y se compilan en políticas de row-level security, de modo que la comprobación está junto a los datos, por debajo del código de la aplicación.
Una sola especificación, compilada
El modelo de acceso vive en un único archivo de especificación. Demesne, nuestro compilador de código abierto, lo convierte en las políticas y en las funciones de base de datos que estas invocan. El SQL generado se publica exactamente como lo escribió el compilador, y nadie lo edita a mano. En el momento de escribir esto gobierna unas cien tablas.
Forzada y comprobada contra el esquema real
La row-level security está forzada en cada tabla gobernada, además de habilitada, lo que cierra la vía por la que el propietario de una tabla lee saltándose una política. Una prueba lee ambos ajustes del catálogo de la base de datos y falla si alguno está desactivado.
Una segunda prueba enumera todas las tablas del esquema y falla ante cualquiera que se haya añadido sin una decisión registrada sobre cómo está protegida.
A qué puede llegar una solicitud
Una solicitud a la API se atiende bajo esas políticas, con el espacio de trabajo, el proyecto y la organización de quien llama como claims que lee la base de datos. La política de cada tabla los compara con la fila antes de considerar cualquier otra regla. Una fila que quien llama no puede ver se comporta como si no existiera.
Dónde decide la aplicación
La base de datos no distingue algunas acciones: publicar un registro es una actualización, en lo que respecta a Postgres. Esos permisos se comprueban cuando llega la solicitud, contra un mapa generado a partir de la misma especificación, y las reglas de fila siguen acotando lo que la acción puede tocar.
Lee cómo funciona
La documentación explica la propiedad, la visibilidad, las concesiones y cómo se resuelve una solicitud para cada tipo de credencial.