Restrinja as tarefas com RLS

O campo user_id relaciona a tarefa a um cadastro. A política compara esse valor com auth.uid(), que representa a identidade autenticada na chamada. A tabela do exercício terá somente leitura e inserção pelo frontend.

Conceda as ações previstas

Execute o SQL no projeto de estudo que contém a tabela tarefas. O trecho retira permissões anteriores dos papéis usados pela API e concede as duas ações necessárias ao exercício.

1
begin;
2
revoke all on public.tarefas from anon, authenticated;
3
grant select, insert on public.tarefas to authenticated;
4
create policy tarefas_leitura on public.tarefas
5
  for select to authenticated
6
  using ((select auth.uid()) = user_id);
7
create policy tarefas_insercao on public.tarefas
8
  for insert to authenticated
9
  with check ((select auth.uid()) = user_id);
10
commit;

A condição using seleciona as linhas visíveis. A condição with check confere o registro que será inserido. O exemplo não concede atualização nem exclusão, por isso essas ações exigiriam permissões e políticas próprias.

Compare duas sessões

Entre com o primeiro cadastro e crie uma tarefa pela aplicação. Depois encerre a sessão e entre com o segundo cadastro. A tarefa do primeiro não deve aparecer. Insira uma tarefa do segundo cadastro e repita a comparação.

Faça também uma tentativa de inserção com o identificador do outro cadastro. A API deve recusar a gravação. Esse teste verifica a permissão mesmo quando o frontend envia um valor adulterado.

Use o cliente da aplicação

Execute a conferência com a chave publishable e as sessões de teste. O SQL Editor usa acesso administrativo e não reproduz esse caminho. Uma consulta administrativa que encontra todas as linhas não invalida o teste feito com a sessão.

A próxima etapa conecta o cliente JavaScript e fornece o código de inserção e leitura para concluir a comparação.