Autenticação, Perfis, Permissões e RLS¶

Sistema: Drexies Agro | Responsável: Equipe de Dados Sonar

Esta página documenta as camadas de autenticação, autorização e segurança de acesso identificadas no código da Drexies Agro.

Camadas de controle de acesso¶

flowchart LR
    C[Credenciais] --> A[Supabase Auth]
    A --> S[Sessão]
    S --> P[user_profiles e user_roles]
    P --> F[Permissões do frontend]
    P --> R[Políticas RLS]
    F --> T[Menu, rotas e telas]
    R --> D[Dados autorizados no PostgreSQL]

Supabase Auth e sessão¶

O login usa supabase.auth.signInWithPassword, com e-mail e senha. O cliente Supabase mantém a sessão no armazenamento configurado pelo projeto, persiste a sessão e renova o token automaticamente.

O AuthContext acompanha as mudanças de autenticação por onAuthStateChange. Na inicialização, também existe uma leitura de contingência por getSession caso o evento inicial não seja recebido dentro do tempo previsto no código.

Após identificar o usuário autenticado, a aplicação consulta:

• user_profiles, usando auth_user_id;
• user_roles, usando user_id.

Se nenhum papel for retornado, o contexto usa user como fallback técnico. O perfil e o papel carregados alimentam o menu, as rotas e as abas de Configurações.

Usuários ativos e inativos¶

O campo ativo pertence a user_profiles. Quando o contexto carrega um perfil inativo, executa signOut e limpa o estado autenticado da aplicação.

Perfis de usuário¶

No contexto da aplicação:

isAdmin = role igual a admin ou global_admin
isGlobalAdmin = role igual a global_admin

Proteção de rotas¶

ProtectedRoute¶

As seguintes rotas usam ProtectedRoute:

O componente aplica o seguinte fluxo:

1. enquanto a autenticação está carregando, apresenta um indicador de carregamento;
2. sem usuário autenticado, redireciona para /login;
3. administradores passam pela restrição de telas sem filtragem;
4. para usuário comum com telas_permitidas preenchida, verifica a chave correspondente à rota;
5. se a tela não estiver autorizada, redireciona para a primeira tela permitida reconhecida ou usa /dashboard como fallback.

As chaves mapeadas são dashboard, visao-macro, visao-micro e estrutura-comercial. Configurações e redefinição de senha não fazem parte desse mapa e, no código atual, exigem autenticação, mas não uma entrada em telas_permitidas.

AdminRoute¶

AdminRoute está efetivamente utilizado na rota /admin/users. Ele:

• redireciona visitantes sem sessão para /login;
• redireciona usuários não administradores para /dashboard;
• permite administradores e administradores globais.

A rota autorizada redireciona para /configuracoes?tab=usuarios.

Permissões de tela e menu¶

O menu lateral possui quatro áreas funcionais controladas por chave:

Para administradores, todos esses itens são exibidos. Para usuários comuns com uma lista preenchida, somente os itens presentes em telas_permitidas aparecem.

O item Configurações é exibido separadamente para usuários autenticados e não é filtrado por telas_permitidas. As funções disponíveis dentro da página são controladas por perfil.

Restrição por concessionária e filial¶

O perfil armazena:

• concessionarias_permitidas;
• filiais_permitidas.

Essas listas podem ser mantidas na Gestão de usuários. Para usuários não administradores, o código aplica os valores como filtros nos dados do Google Sheets usados em Potencial de Mercado e Produtores. Administradores ignoram esses filtros no frontend.

Quando uma lista territorial está preenchida, somente valores correspondentes permanecem nos dados filtrados. A tela de gestão também restringe a seleção de filiais às concessionárias escolhidas.

Configurações, usuários e auditoria¶

Se uma aba não autorizada for solicitada por parâmetro da URL, a página seleciona ou retorna para a aba Geral.

Gestão de usuários¶

A interface de usuários consulta user_profiles e user_roles. Ela permite manter nome, situação, papel, concessionárias, filiais e telas permitidas, conforme os controles disponíveis para o administrador.

Criação, exclusão e redefinição administrativa de senha utilizam a Edge Function manage-users. Atualizações de perfil e papel também usam as tabelas correspondentes, sujeitas às políticas e aos gatilhos do banco.

Auditoria¶

Os registros são mantidos em drexies_audit_log. A aba de Auditoria é apresentada somente ao Administrador Global no frontend.

As migrations mais recentes analisadas substituem políticas anteriores e criam uma política de leitura para administradores globais. Usuários autenticados podem inserir os próprios eventos quando atendem à política definida.

Edge Function manage-users¶

A função exige o cabeçalho de autorização, valida o usuário chamador no Supabase Auth e consulta user_roles. Apenas admin ou global_admin podem prosseguir.

A Edge Function usa a chave de service_role para operações privilegiadas. Essa chave não é exposta ao frontend pelo fluxo analisado.

Contas protegidas¶

O código contém proteção especial para conta identificada por e-mail:

• a interface impede que outros administradores editem a conta;
• manage-users impede sua exclusão;
• a função is_protected_user identifica a conta no banco;
• gatilhos sobre user_roles mantêm o papel global_admin e impedem sua remoção;
• gatilhos sobre user_profiles impedem exclusão e preservam campos de acesso quando outro usuário tenta alterá-los;
• quando a própria conta altera o perfil, o campo ativo permanece verdadeiro.

Os privilégios de execução das funções de proteção são revogados de PUBLIC, anon e authenticated em migration posterior.

Logout¶

Logout manual¶

O menu do usuário oferece a ação Sair, que chama supabase.auth.signOut. A mudança de autenticação limpa o usuário, a sessão, o perfil e o papel mantidos pelo contexto; rotas protegidas passam a redirecionar para o login.

Logout automático por inatividade¶

O AuthContext configura logout após duas horas sem interação. O temporizador é reiniciado por eventos de clique, teclado, entrada, alteração, rolagem, movimento do mouse, toque, ponteiro e foco. O processamento desses eventos possui limitação técnica de 15 segundos para evitar reinicializações excessivas.

Ao atingir o limite, a aplicação executa signOut e direciona o navegador para /login.

Estruturas relacionadas a acesso¶

Padrões de RLS identificados nas migrations¶

As migrations locais habilitam RLS em tabelas do sistema e apresentam os seguintes padrões:

Há migrations que revisam políticas antigas, inclusive substituindo regras amplas por regras baseadas em usuário ativo ou propriedade do registro.

Interface versus segurança no banco¶

Uma operação sensível deve depender de controles do backend e do banco, mesmo quando a interface já esconde a ação.

Pontos a validar¶

1. Confirmar se telas_permitidas vazia deve conceder todas as telas aos usuários comuns, como ocorre no frontend atual.
2. Construir a matriz final de RLS por tabela e operação a partir das políticas efetivamente implantadas.
3. Confirmar as contas protegidas configuradas no ambiente publicado.
4. Comparar funções, gatilhos, enum de papéis e políticas locais com o Supabase remoto.
5. Validar a matriz completa de ações permitidas para Administrador Global, Administrador e Usuário.
6. Definir o comportamento para identidade autenticada sem user_profiles correspondente.
7. Confirmar o significado de listas vazias de concessionárias e filiais e a abrangência territorial esperada.
8. Verificar se o escopo territorial precisa ser imposto por RLS ou backend, além dos filtros atuais do frontend.
9. Confirmar se é intencional utilizar user como fallback técnico para um usuário autenticado que possua perfil, mas não possua papel correspondente em user_roles.

Referências¶

• Primeiros Passos — login, navegação e encerramento da sessão
• Telas e Funcionalidades — áreas funcionais e restrições apresentadas ao usuário
• Fontes de Dados e Linhagem — tabelas, funções e integrações do Supabase