Console Admin
Métricas, ferramentas de dev e demo de paywalls. Como abrir, o que cada aba mostra e como dar acesso.
Console em tela cheia na rota /admin. Serve dois públicos: administradores (dados reais de produção) e desenvolvedores (ferramentas de debug).
Implementação
-
Para abrir, toque duas vezes no número de versão no rodapé de Configurações. Em debug, o console também aparece como link direto em Configurações.
-
Para dar acesso admin a alguém, defina o campo
role = "admin"no banco, nunca pelo app:- Firebase: Firestore → coleção
users→ documento do usuário → adicionerole = admin - Supabase: Table editor → tabela
users→ colunarole = admin - API: seu servidor devolve e protege o campo
role
Para encontrar o ID do usuário: abra o console Admin → Ferramentas → Copiar UID, ou veja a Visão geral da sessão atual.
Firestore: documento do usuário com o campo role: 'admin' adicionado O
rolesó pode ser gravado pelo servidor, nunca pelo app. Qualquer tentativa do cliente de alterarroleé bloqueada nos três backends (Firestore rules / trigger Supabase / validação no seu servidor). Isso é intencional: senão qualquer usuário viraria admin. - Firebase: Firestore → coleção
Informações
Quem vê o quê
O acesso usa duas chaves independentes:
Debug (kasy run) | Produção (build de release) | |
|---|---|---|
| Abrir o console | Qualquer dev | Só admin |
| Ferramentas de dev (abas Kit e Ferramentas) | Sim | Não aparecem |
| Dados reais de usuários | Só admin | Só admin |
| Demo de paywalls/ads | Admin (sempre teste) | Admin |
Resumo: debug abre as ferramentas de dev; o campo role abre os dados de produção.
Abas disponíveis
| Aba | Conteúdo | Requer role admin? | Some em release? |
|---|---|---|---|
| Visão geral | Backend ativo, sessão atual, contagem de solicitações | Parcial | Não |
| Usuários | Tabela com busca, filtro de assinantes, paginação | Sim | Não |
| Solicitações | Feature requests dos usuários (moderar, editar texto) | Sim | Não |
| Kanban | Board de tarefas do projeto (ver Kanban), só aparece se o módulo estiver ligado | Sim | Não |
| Enviar push | Formulário de push em massa | Sim | Não |
| Kit | Demos de features e galeria de componentes | Não (dev) | Sim |
| Ferramentas | Dev Inspector, paywalls, anúncios, copiar UID/FCM, testar onboarding | Não (dev) | Sim |
Lembra última seção (só em debug)
Em debug, o console reabre na última aba que você acessou, assim você não precisa navegar toda vez para onde estava trabalhando. Em release, sempre cai na Visão geral.
Ainda em debug, o atalho "Admin" de Configurações abre direto no Kanban em vez da Visão geral, para não disparar as consultas do dashboard quando você só quer mexer nas tarefas. Para que o debug se comporte como produção nesse ponto, mude kDebugAdminOpensKanban para false em lib/core/navigation/admin_routes.dart.
Como o role é protegido em cada backend
O user.isAdmin do app (que compara role == "admin") serve só para mostrar ou esconder interface. Toda leitura de dado real é validada de novo no servidor:
| Backend | Bloqueio de escrita do role | Leitura dos usuários pelo admin |
|---|---|---|
| Firebase | As regras do Firestore bloqueiam qualquer escrita do cliente no campo role | Cloud Function listUsers confere role == "admin" pelo Admin SDK antes de devolver dados |
| Supabase | Trigger enforce_role_immutable impede anon e authenticated de gravar role; só service_role e o painel passam | Edge Function admin-list-users valida o role pelo JWT de quem chamou e só então usa o service_role |
| API REST | Seu servidor devolve o role e precisa rejeitar qualquer tentativa do cliente de gravá-lo | Endpoint GET /admin/users que valida role == "admin" e responde 403 caso contrário |
Atualizado em 03/11/2026