Regras de acesso na exportação

O que as políticas reproduzem

O bundle de exportação inclui policies.sql, que configura a row-level security nas tabelas exportadas. Um usuário vê uma linha quando é dono dela, quando ela é pública, quando ele recebeu acesso explícito a ela, ou quando ela depende de algo que ele já pode ver. Esse último caso alcança um nível, por uma referência que carrega acesso de leitura. As concessões explícitas viajam em uma tabela própria, que as políticas consultam e que os usuários não podem ler diretamente.

Dentro do Fóir, as regras são impostas no banco de dados, compiladas pelo Demesne contra uma única tabela de registros. A exportação tem uma tabela por modelo, então as mesmas regras são escritas de novo para esse formato.

Aplicando as políticas

Você executa o arquivo com psql depois que os dados forem carregados. Aplicar o bundle pelo comando de exportação não o executa. A partir daí, o contrato é uma configuração de sessão, request.jwt.claims, carregando o id do usuário. Sem claims definidos, o chamador é anônimo e vê exatamente as linhas públicas. Teste com o papel authenticated porque o papel que restaurou as tabelas é dono delas, e o dono de uma tabela ignora a row-level security.

O que não é transferido

Permissões por campo, os escopos de API e as regras de gravação ficam para trás. Um usuário que vê uma linha no banco restaurado vê todas as colunas dela, então ocultar um campo passa a ser tarefa da sua aplicação, de uma concessão de coluna ou de uma view. As políticas dão a chamadores anônimos e logados apenas acesso de leitura, e o acesso da sua equipe ao console não é exportado.

O que é testado

Nossa suíte de testes exporta um projeto com dados de seed, restaura em um segundo banco, aplica as políticas e exige os mesmos ids de linha para o mesmo usuário nos dois lados. Isso testa a tradução, e nada verifica as políticas no seu próprio banco restaurado. Não afirmamos que as regras restauradas coincidam em um projeto que usa organizações.