FINDER
Aplicativo de comunidade e matchmaking de Free Fire, com MVP funcional, integração com Google Apps Script e evolução para autenticação real com Supabase.
Stack atual
- Next.js 16
- React 19
- TypeScript
- Tailwind CSS
- App Router
- Google Apps Script como camada de compatibilidade temporária
- Supabase Auth + PostgreSQL para identidade e perfis
Fluxo de desenvolvimento recomendado
- Manter o MVP público funcionando sem alterações destrutivas.
- Usar variáveis de ambiente para todas as integrações externas.
- Preparar a base do Supabase antes de mover regras de negócio críticas.
- Proteger rotas privadas no servidor e nunca confiar no client para autorização.
- Mantenha a compatibilidade com o Apps Script legado até que a migração esteja concluída.
Variáveis de ambiente
Crie um arquivo .env.local baseado em .env.example:
NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key
SUPABASE_SERVICE_ROLE_KEY=your-service-role-key
NEXT_PUBLIC_APP_URL=http://localhost:3000
LEGACY_APPS_SCRIPT_URL=https://script.google.com/macros/s/your-script/exec
Nenhuma chave sensível deve ser exposta no cliente. Apenas as chaves públicas do Supabase e a URL da aplicação devem ficar em NEXT_PUBLIC_*.
Scripts
npm install
npm run dev
npm run build
npm run lint
Fase 2: identidade e autorização
A implementação atual inclui:
- cadastro com email/senha usando Supabase Auth
- login e logout
- recuperação de senha
- sessão persistente via
@supabase/ssr
- middleware para bloquear rotas privadas
- dashboard e perfil protegidos no servidor
- área administrativa somente para
ADMIN
- criação automática de perfil vinculado a
auth.users.id
- políticas de RLS para acesso próprio e controle de role
Como funciona a autenticação
- O cadastro cria um usuário em
auth.users.
- O trigger de banco cria ou atualiza o registro em
public.profiles.
- O perfil usa o
id do usuário do Supabase como referência principal.
- Todo novo usuário entra com
role = 'USER' por padrão.
- Somente o banco ou um fluxo administrativo seguro pode promover um usuário para
ADMIN.
Proteção de rotas
/dashboard, /perfil e /admin são protegidas no servidor.- Se a sessão não existe, o usuário é redirecionado para
/login.
- A área
/admin também valida o perfil do usuário no banco e exige role = 'ADMIN'.
- O cliente nunca decide autorização: o backend e o middleware fazem a validação final.
Role e admin
- Padrão:
USER
ADMIN deve ser concedido apenas por um processo confiável no Supabase/SQL.- O frontend não pode alterar a própria role.
- Usuários comuns que tentarem acessar
/admin são redirecionados para /dashboard.
Processo seguro para primeiro ADMIN
- Criar um usuário normal pelo fluxo de cadastro.
- Acessar o painel do Supabase.
- Verificar a tabela
public.profiles.
- Alterar manualmente
role para ADMIN no banco, preservando a regra de segurança e o vínculo com auth.users.id.
- Validar a sessão e acessar
/admin.
Evite criar ADMIN via cliente ou pela UI pública.
RLS e privacidade
- Usuários só podem ler/editar o próprio perfil.
- A role não pode ser alterada por um usuário comum.
- Políticas administrativas são restritas a usuários com
role = 'ADMIN'.
USING (true) para dados privados não deve ser usado em tabelas sensíveis.
Estrutura relevante
lib/auth.ts — helpers de sessão, perfil e autorizaçãolib/supabase/config.ts — configuração pública do Supabaselib/supabase/client.ts — cliente browserlib/supabase/server.ts — cliente server-sideproxy.ts — proteção de rotas privadas no padrão atual do Next.jsdocs/supabase/schema.sql — schema base de banco e RLSapp/dashboard/page.tsx — área privada principalapp/admin/page.tsx — área administrativaapp/perfil/page.tsx — página de perfil do usuário
Compatibilidade
O Apps Script continua em uso como camada de compatibilidade temporária para o MVP público. Isso preserva feedback, waitlist, oportunidades, mentorias e demais páginas públicas sem quebrar o app existente.
