Imposto no banco de dados
Quem pode ler ou alterar uma linha no Fóir é decidido pelo Postgres. As regras são escritas uma vez, em uma única spec, e compiladas em políticas de row-level security, de modo que a verificação fica junto dos dados, abaixo do código da aplicação.
Uma spec, compilada
O modelo de acesso vive em um único arquivo de spec. Demesne, nosso compilador open source, o transforma nas políticas e nas funções de banco de dados que elas chamam. O SQL gerado é entregue exatamente como o compilador o escreveu, e ninguém o edita à mão. No momento em que escrevemos, ele governa cerca de cem tabelas.
Forçada e verificada contra o schema em produção
A row-level security é forçada em toda tabela governada, além de habilitada, o que fecha o caminho pelo qual o dono de uma tabela lê passando por cima de uma política. Um teste lê as duas configurações no catálogo do banco e falha se alguma estiver desligada.
Um segundo teste lista todas as tabelas do schema e falha em qualquer uma que tenha sido adicionada sem uma decisão registrada sobre como ela é protegida.
O que uma requisição consegue alcançar
Uma requisição à API é atendida sob essas políticas, carregando o workspace, o projeto e a organização do chamador como claims que o banco lê. A política de cada tabela os compara com a linha antes de qualquer outra regra ser considerada. Uma linha que o chamador não pode ver aparece como se não existisse.
Onde a aplicação decide
O banco não consegue distinguir algumas ações: publicar um registro é um update, no que diz respeito ao Postgres. Essas permissões são verificadas quando a requisição chega, contra um mapa gerado a partir da mesma spec, e as regras de linha ainda limitam o que a ação pode tocar.
Leia como funciona
A documentação cobre propriedade, visibilidade, concessões e como uma requisição é resolvida para cada tipo de credencial.