Supabase: guia para perceber autenticação, dados e permissões

Estás a construir uma app com IA. A página já abre, o formulário tem bom aspeto e o botão de entrar funciona. Depois pedes para guardar projetos, associar documentos e criar uma área para cada cliente. É aqui que precisas de perceber como a informação fica organizada e protegida.

Não tens de começar por decorar comandos. Começa por escrever quem usa a aplicação e que operações pode executar. Se essa decisão estiver indefinida, o agente vai ter de preencher lacunas enquanto constrói. Algumas dessas escolhas afetam diretamente o acesso de uma pessoa ao trabalho de outra.

Este guia usa uma aplicação fictícia de propostas, com duas contas de teste. Explica os conceitos e propõe verificações; não apresenta uma configuração pronta para copiares para produção. A documentação oficial foi conferida em 17 de outubro de 2026. Não foram criados projetos, contas ou tabelas para este artigo.

O que faz o Supabase numa aplicação?

O Supabase pode fornecer a base de dados, a gestão de identidade e o armazenamento de ficheiros que a tua aplicação utiliza. O código da aplicação define o percurso e as operações disponíveis. Precisas de relacionar esses componentes com o resultado pretendido, em vez de assumir que ligar um serviço completa o projeto.

A documentação da base de dados do Supabase apresenta o Postgres como base do serviço e explica a ligação com outros componentes da plataforma. Para quem está a começar, interessa perceber que os dados persistentes têm uma estrutura própria, separada do aspeto das páginas.

Numa app de propostas, a página mostra os campos e os botões. A base de dados guarda propostas, estados e associações aos respetivos responsáveis. A autenticação identifica a pessoa que entrou. As regras de acesso determinam o que essa pessoa pode consultar ou alterar.

Se acrescentares anexos, tens ainda o armazenamento dos ficheiros e os respetivos acessos. Se enviares emails, tens outra integração e regras sobre quando o envio acontece. Cada componente precisa de um critério de funcionamento que consigas observar.

Nas aulas do Lab, a construção por etapas aparece associada a esta separação de responsabilidades. Começar pela estrutura visual ajuda a discutir o percurso, mas as decisões sobre dados e autorização devem entrar no plano desde o início.

Autenticação e autorização: qual é a diferença?

Autenticação confirma a identidade de quem entra; autorização decide os recursos e as ações a que essa identidade tem acesso. Duas pessoas podem iniciar sessão corretamente e ter permissões diferentes. Define essas regras para cada operação, incluindo consultar, criar, editar e apagar, antes de considerares concluída a área privada da aplicação.

Na aplicação fictícia, a Ana e o Bruno têm contas próprias. Ambos conseguem entrar. A Ana deve consultar as suas propostas, e o Bruno as dele. O facto de ambos terem login não significa que possam consultar a lista completa da empresa.

A documentação do Supabase Auth distingue estas responsabilidades e explica a ligação entre identidade, tokens de sessão e políticas de acesso aos dados. O serviço fornece mecanismos; as regras concretas do teu produto têm de ser definidas e implementadas.

Escreve primeiro uma frase simples: «Cada utilizador gere apenas as propostas que lhe pertencem.» Depois detalha as exceções. Existe um gestor que pode consultar todas? Pode também editar? Pode atribuir uma proposta a outra pessoa? Quem decide que uma conta passa a gestor?

Se ainda não precisas dessas exceções, deixa-as fora do primeiro exercício. Uma aplicação pequena com regras claras é mais fácil de testar. Acrescenta a gestão de equipa quando tiveres definido o comportamento e os testes correspondentes.

O guia sobre preparar o briefing de uma aplicação com IA ajuda-te a transformar estas decisões em requisitos que o agente consegue seguir.

Como organizar os dados do primeiro exemplo?

Escolhe uma entidade principal e identifica os campos necessários para a utilizar e proteger. No exemplo, cada proposta precisa de um identificador, um título, um estado e uma associação ao proprietário. Define quais os campos obrigatórios e quem os pode alterar, mantendo os dados de teste simples e inteiramente fictícios.

Podes começar com duas propostas: «Página da loja», pertencente à Ana, e «Catálogo da oficina», pertencente ao Bruno. Esses nomes servem para reconhecer os registos durante o teste. A associação deve usar identificadores estáveis, em vez de depender de nomes escritos à mão.

O formulário pode pedir título e descrição. A identidade do proprietário deve resultar da sessão validada, de acordo com o desenho da aplicação. Um campo oculto no formulário continua a ser informação enviada pelo navegador e pode ser alterado por quem faz o pedido.

Também deves limitar os estados permitidos. Se o produto trabalha com rascunho, em revisão e concluída, explica o significado de cada um. Decide quem pode fazer cada transição. Uma caixa de texto livre para o estado torna mais difícil garantir consistência.

Mantém o primeiro exercício sem pagamentos, comunicações ou ficheiros reais. Assim consegues verificar a associação entre conta e proposta antes de acrescentar efeitos externos. Para decidir se o teu caso já precisa desta estrutura, lê quando mudar de uma folha de cálculo para uma base de dados.

O que significa RLS e porque aparece no Supabase?

RLS significa Row Level Security e permite aplicar regras aos registos dentro da base de dados. No teu projeto, essas regras devem corresponder às operações e aos utilizadores previstos. Confirma também as permissões gerais das tabelas, porque ativar uma opção sem rever o conjunto de acessos não demonstra o comportamento final.

A documentação de RLS do Supabase explica a combinação entre permissões da tabela e políticas por registo. Para tabelas expostas pela API, indica a necessidade de ativar RLS e definir as operações permitidas. Os testes devem verificar tanto o acesso autorizado como a recusa esperada.

No exemplo, a leitura deve limitar-se às propostas associadas à pessoa autenticada. A criação deve impedir que essa pessoa atribua uma proposta a outra conta sem ter essa autorização. A edição também precisa de impedir a mudança indevida de proprietário.

Essas regras não ficam comprovadas só porque a página mostra uma lista curta. O código do navegador pode estar a filtrar uma lista maior que já recebeu. O teste deve verificar a resposta efetiva do serviço e os registos afetados por cada operação.

A documentação do PostgreSQL sobre políticas por registo distingue políticas de consulta e de modificação e descreve acessos privilegiados que podem contornar RLS. Por isso, um teste feito com uma conta administrativa não representa necessariamente a experiência do utilizador normal.

Que verificações devem existir no servidor?

O servidor deve validar a sessão, os campos recebidos e a autorização para a operação pedida. Quando recebe o identificador de uma proposta, precisa de confirmar que essa pessoa pode aceder-lhe. Mantém também as regras da base de dados, para que a proteção não dependa apenas do percurso visível na página.

Imagina um pedido para editar a proposta da Ana. O servidor não deve aceitar a operação apenas porque recebeu um identificador válido e uma sessão qualquer. Precisa de relacionar essa sessão com a proposta e com a regra de edição definida.

O mesmo se aplica a um campo que diga «sou administrador». A aplicação deve obter esse papel a partir de informação controlada no servidor e na base de dados. Um valor escolhido no formulário, no navegador ou num campo de perfil livremente editável não serve para conceder esse acesso.

Pede ao agente que identifique onde cada verificação acontece. Uma resposta útil aponta a operação, a origem da identidade e o critério de autorização. «A página está protegida» é uma descrição demasiado vaga para avaliar a implementação.

Confere ainda os valores recebidos: comprimento do título, estados admitidos e campos que podem ser alterados. A aplicação pode apresentar ajuda no formulário, mas deve repetir a validação no servidor e usar as restrições adequadas na base de dados.

Que chaves podem aparecer na aplicação?

Distingue as chaves destinadas a componentes públicos das credenciais com acesso elevado. Uma chave publicável identifica a aplicação e exige regras corretas de acesso aos dados. As chaves secretas ficam em componentes controlados no servidor. Não as coloques no navegador, em capturas partilhadas ou no código guardado num repositório.

A referência oficial das chaves do Supabase apresenta as chaves publicáveis e secretas e distingue-as das versões antigas chamadas anon e service_role. As secretas têm acesso elevado e contornam RLS. A identidade do utilizador continua a ser uma questão separada da identificação da aplicação.

No primeiro exercício, pede ao agente uma lista dos nomes das variáveis necessárias e do local onde são utilizadas, sem mostrar os valores. Confere quais chegam ao navegador e quais ficam no servidor. O nome de uma variável deve refletir o seu uso, mas o nome, por si só, não comprova que o segredo ficou protegido.

Se uma consulta falhar por falta de autorização, não resolvas a falha acrescentando uma chave administrativa ao código do cliente. Identifica a causa: sessão ausente, associação incorreta, política inadequada ou operação não permitida. A correção deve preservar a regra que queres aplicar.

Ao usares um agente, mantém também os segredos fora do pedido e dos exemplos que partilhas. Podes explicar a configuração através de nomes e valores fictícios, sem copiar credenciais reais para a conversa.

Como testar com duas contas e sem sessão iniciada?

Prepara duas contas de teste e registos distintos, depois compara o resultado de cada operação com a regra escrita. Usa sessões separadas e inclui uma tentativa sem autenticação. Verifica a leitura e a escrita, incluindo pedidos feitos diretamente à aplicação, para não depender apenas da existência ou ausência de botões.

Esta matriz é uma proposta para o exemplo fictício. Não é um relatório de testes já executados:

Inclui também a eliminação, se essa operação fizer parte do produto. Depois de cada tentativa recusada, confirma que o registo não mudou. Uma mensagem de erro no ecrã pode aparecer depois de uma escrita parcial; deves conferir o estado final.

Se a aplicação devolver uma lista vazia, verifica se isso corresponde ao esperado. No teste positivo da Ana, uma lista vazia é uma falha. No teste de acesso indevido do Bruno, interessa confirmar a ausência dos dados da Ana e a forma como a aplicação comunica a recusa.

Para organizar esta revisão, tens o artigo sobre testar permissões antes de abrir uma aplicação a utilizadores. Guarda o resultado observado, a conta usada e o estado dos dados, sem registar palavras-passe ou tokens.

E se a proposta tiver ficheiros anexos?

Trata os anexos como recursos com regras próprias de acesso, mesmo quando estão associados a uma proposta protegida. Define quem pode enviar, consultar, substituir e apagar cada ficheiro. Confirma o acesso ao conteúdo real e não apenas à linha que apresenta o nome do anexo dentro da aplicação.

A documentação de controlo de acesso do Storage descreve políticas para as operações sobre ficheiros. Uma permissão de envio não equivale automaticamente a todas as restantes operações. O teste deve acompanhar o uso concreto que implementaste.

No exemplo, começa por um PDF fictício sem dados de clientes. A Ana deve conseguir anexá-lo à sua proposta. O Bruno não deve conseguir obtê-lo por copiar o endereço ou trocar um identificador no pedido, se o ficheiro foi definido como privado.

Não uses uma pasta chamada «privado» como prova de proteção. Confere as permissões efetivas e a forma como a aplicação disponibiliza o ficheiro. Se o servidor emitir uma ligação temporária, deve verificar primeiro se a pessoa pode aceder ao anexo.

Define também tipos e tamanhos permitidos. O destino do ficheiro deve ser determinado de forma controlada, sem aceitar livremente um caminho enviado pelo utilizador. Verifica o que acontece quando o envio falha ou quando a proposta é apagada: a ligação entre registo e ficheiro precisa de tratamento explícito.

Como pedir à IA que implemente isto por etapas?

Entrega ao agente o objetivo, os dados fictícios, as regras de acesso e os testes esperados. Pede uma implementação pequena com evidência por etapa. Mantém explícito o ambiente autorizado e os limites de publicação. O agente deve explicar o que verificou e o que falta verificar antes de avançar.

Podes adaptar este pedido:

Quero preparar uma app de propostas num ambiente de teste. Cada utilizador gere apenas as suas propostas. Começa por rever a estrutura existente e explicar autenticação, tabelas, operações no servidor e políticas de acesso. Usa duas contas e dados fictícios nos testes. Não alteres produção nem uses dados de clientes. Mostra os resultados dos casos permitidos e recusados, sem imprimir segredos.

Antes de executar, resolve as decisões que afetam o comportamento: existe partilha, há gestores, quem pode apagar e que campos podem mudar? O agente pode ajudar a listar opções, mas deve trabalhar com a regra escolhida.

Pede também uma descrição das alterações que permitiria regressar à versão anterior. Uma mudança de dados pode exigir mais do que voltar atrás no código. Preserva o estado anterior e testa a recuperação numa cópia adequada ao exercício.

Nas unidades do Lab sobre portabilidade e continuidade, esta distinção é central: o repositório guarda código, enquanto a aplicação também depende de dados, autenticação, ficheiros e configuração. Inventaria esses componentes antes de mudares de ferramenta ou alojamento.

O que deve estar confirmado antes de publicar?

Confirma o percurso principal, os acessos entre contas, a proteção dos segredos e a recuperação dos componentes necessários. Repete os testes relevantes no ambiente final autorizado, porque configuração local e configuração publicada podem diferir. Mantém um registo claro das verificações e das limitações, com um responsável por tratar falhas.

Ver uma proposta guardada na tua conta de administrador é um primeiro sinal de funcionamento. Para abrir a aplicação, precisas de conferir as contas normais, as operações recusadas e os ficheiros associados. Inclui o fim da sessão e o regresso a uma página privada.

Não apresentes os testes deste exemplo como uma auditoria completa. Servem para verificar regras concretas da primeira versão. Novas funções, partilha entre equipas ou integrações acrescentam comportamentos que terão de entrar no plano de testes.

O objetivo é conseguires explicar o percurso de uma operação: quem a pediu, que regra foi aplicada, que dados foram usados e qual foi o resultado. Essa clareza ajuda-te a construir com IA e a perceber quando precisas de rever a implementação.

Aprende no Laboratório a construir com regras claras

No Laboratório da IA, podes trabalhar o teu projeto por etapas, desde o briefing até à verificação do comportamento. As aulas semanais e os Zooms de acompanhamento semanais ajudam-te a esclarecer decisões e dificuldades. Leva um exemplo pequeno, com utilizadores definidos e uma regra de acesso que consigas testar.

Começa por uma operação simples: criar e consultar uma proposta própria. Depois acrescenta edição, anexos ou partilha, sempre com critérios concretos. Assim consegues discutir a aplicação pelo que faz e pela forma como protege o trabalho de cada pessoa.