Mantenha os Dados de Cada Cliente na Conta Certa

Um app pode parecer perfeito enquanto só você o utiliza. O problema aparece quando uma segunda pessoa entra. Um cliente pode abrir a lista de pedidos e encontrar o pedido de outro cliente. Um membro pode alterar uma anotação escrita por outra pessoa. Entrar na conta não impede isso automaticamente. Essa entrada apenas informa ao app qual conta está presente. Ainda é preciso tomar uma decisão separada para cada item que será mostrado ou alterado.

O Supabase mantém as informações em grupos organizados. O nome técnico desse armazenamento organizado é banco de dados, e cada grupo é chamado de tabela. Uma tabela pode guardar perfis, reservas, tarefas, mensagens ou pedidos. O Supabase consegue examinar um item salvo por vez e decidir se a pessoa atual pode usá-lo. O nome técnico é Row Level Security, muitas vezes abreviado como RLS. Essas regras ficam junto dos dados salvos, por isso a proteção não depende apenas de uma tela esconder um botão ou filtrar uma lista.

Imagine uma reserva como uma linha de caderno. Essa linha precisa de uma marca confiável que identifique seu dono. Sem ela, o app não consegue separar com segurança a reserva de um cliente da reserva de outro. O nome exibido não basta, pois duas pessoas podem escolher o mesmo nome. Um e-mail digitado em um formulário também não prova nada, porque alguém pode informar o endereço de outra pessoa. A marca de dono deve vir da conta que já entrou no app.

O Supabase fornece uma identidade estável para cada conta conectada. O nome técnico é identificador de usuário. Salve esse identificador em todo item que pertence a uma pessoa. Quando uma anotação ou um pedido for criado, o Supabase deve usar a identidade da conta atual, sem confiar em um dono informado pela tela do visitante. A tela é a parte visível em que a pessoa toca ou clica; ela pode pedir uma ação, mas não deve escolher quem será o dono do resultado. Defina também como funcionam itens compartilhados, como uma reserva visível para o cliente e para o funcionário responsável.

Um cliente pode precisar ver uma reserva, mas não cancelá-la depois que o atendimento começou. Uma pessoa do suporte pode precisar ler a dúvida de um cliente sem alterar o perfil dele. Quem pode criar um comentário não deve ganhar automaticamente o poder de editar todos os comentários. Trate ver, criar, editar e excluir como quatro escolhas separadas. Dê a cada pessoa somente as ações necessárias para o funcionamento do app.

O Supabase representa cada escolha como uma regra aplicada aos dados. O nome técnico é policy, chamada de política em português. Uma política pode cuidar da leitura, criação, edição ou exclusão de itens salvos. Na documentação do Supabase, essas ações podem aparecer como select, insert, update e delete. Comece com a menor regra útil: uma pessoa comum conectada só pode usar um item cujo identificador de dono seja igual ao identificador dela. Depois, acrescente exceções bem definidas para necessidades reais, como um funcionário responsável consultar um pedido de suporte. Evite uma regra ampla para toda a equipe quando funções diferentes precisam de dados diferentes.

Sua conta de dono pode ter poderes que um cliente comum não possui. Se você testar somente com ela, uma regra ausente pode parecer correta. Crie duas contas de teste sem informações reais de clientes. Coloque em cada conta itens de exemplo bem diferentes, como uma anotação azul em uma e uma anotação laranja na outra. Assim, qualquer mistura fica fácil de perceber.

Use a primeira conta para conferir listas, páginas de cada item, buscas, formulários de criação, edição e exclusão. Recarregue as páginas importantes e abra diretamente os endereços de páginas salvas. Depois, repita tudo com a segunda conta. Não considere um menu escondido como prova, pois ocultar um botão não significa proteger os dados salvos. O nome técnico da verificação que confirma se a pessoa certa é aceita e a pessoa errada é recusada é teste de autorização. Anote o resultado esperado antes de testar, incluindo uma recusa clara quando uma conta tenta usar o item de exemplo da outra.

Uma ferramenta de IA pode adicionar favoritos, avisos, conversas, documentos gerados ou dados de arquivos quando você pede um recurso novo. Ela também pode criar uma tabela mesmo que você não tenha pedido isso pelo nome. Trate cada novo lugar que salva informações como uma nova decisão de pertencimento. Antes de publicar a mudança, confirme quem é o dono de cada item, o que uma pessoa comum pode fazer e se o Supabase verifica todos os registros envolvidos.

Examine também os arquivos enviados aos visitantes. Senhas, chaves de pagamento e códigos de acesso capazes de abrir dados de clientes ou gastar dinheiro devem permanecer em uma parte protegida do app que o visitante não consegue baixar. Os desenvolvedores chamam essa parte protegida de lado do servidor. Depois de mudanças importantes, repita os testes com duas contas. A VibeCodeWall verifica o app público pelo lado de fora; ela não vê código particular. Também pode continuar acompanhando mudanças importantes no app público ao longo do tempo. Essa visão externa complementa sua revisão e seus testes, mas não substitui nenhum dos dois.