Contas de utilizador & login

A mensagem que muda tudo

Uma semana depois da publicação online, o Tom recebe o feedback que mais se repete. A Lina, uma aluna do 7.º ano, escreve-lhe: «Professor, marquei todos os meus hábitos no computador da biblioteca, e à noite no meu telemóvel tinha desaparecido tudo!» O Tom percebe imediatamente: tinha escolhido o armazenamento local no capítulo 3, e o localStorage guarda os dados no navegador de cada aparelho. O computador da biblioteca e o telemóvel da Lina são dois mundos separados que não falam entre si. Para que a app siga a Lina para todo o lado, tem de poder reconhecê-la — e reconhecer alguém, na web, chama-se uma conta de utilizador.

Lembra-te: no capítulo 3, «conta de utilizador» figurava na lista das palavras-armadilha a banir da tua v1. Não era uma proibição definitiva, era uma questão de timing. O Tom primeiro construiu, implementou, e recolheu feedback real. Agora, a necessidade já não é uma hipótese: é o pedido número um dos seus utilizadores. É exatamente a ordem certa — a complexidade justifica-se por uma necessidade provada, nunca por um «por via das dúvidas». Vais ver que esta complexidade, bem abordada, está perfeitamente ao teu alcance.

Autenticação: o que se passa realmente

Três palavras de vocabulário vão transformar os teus diálogos com a IA sobre este assunto. A autenticação é provar quem és («sou mesmo a lina@escola.pt»). A sessão é continuar reconhecido durante algum tempo sem ter de o provar a cada clique — é ela que faz com que não tenhas de te voltar a ligar a cada trinta segundos. A autorização é o que tens o direito de ver ou de fazer depois de reconhecido («a Lina vê OS hábitos dela, não os dos outros»). Quando usares estas palavras nos teus prompts, a IA saberá exatamente de que falas.

Por trás de um simples ecrã de login esconde-se na realidade todo um sistema: o registo, o login, o logout, a recuperação em caso de esquecimento, a proteção contra robôs, o armazenamento seguro das credenciais… Construir tudo isto sozinho é demorado e, sobretudo, perigoso: o mínimo erro expõe os dados dos teus utilizadores. A boa notícia é que ninguém o constrói sozinho hoje em dia — nem mesmo os profissionais. Toda a gente se apoia em serviços especializados que resolveram o problema de uma vez por todas.

Os serviços de autenticação prontos a usar

Estes serviços chamam-se por vezes BaaS (Backend as a Service): fornecem à tua app os tijolos de servidor de que ela precisa — incluindo a autenticação — sem que tenhas de gerir um servidor. Crias uma conta neles, recuperas duas chaves, e a tua app delega-lhes todo o trabalho sensível. Três nomes aparecem em todo o lado, e a IA conhece-os de cor:

Para este curso, seguiremos o Tom no Supabase: a oferta gratuita cobre largamente uma app de turma, e o facto de ter a autenticação e a base de dados no mesmo sítio vai simplificar o capítulo 7. Mas retém o princípio mais do que o nome — o método que vais aprender aplica-se tal e qual nos concorrentes.

Que método de login para os teus utilizadores?

Existem três grandes formas de fazer login, e a boa escolha depende inteiramente de quem são os teus utilizadores. A palavra-passe clássica é universal mas penosa: as pessoas esquecem-na, reutilizam-na em todo o lado, e é preciso gerir a recuperação. O login via Google ou Apple («OAuth») é confortável… desde que os teus utilizadores tenham uma conta Google que usem realmente. O link mágico (magic link) elimina pura e simplesmente a palavra-passe: o utilizador escreve o email, recebe um link, clica, e fica ligado.

• Palavra-passe: universal, mas esquecimentos frequentes e gestão de recuperação obrigatória.
• Login Google / Apple: um clique e está feito — se os teus utilizadores tiverem (e usarem) essas contas.
• Link mágico: nada para decorar, nada para esquecer. Perfeito para utilizadores ocasionais ou jovens. Única exigência: aceder à caixa de email.

O Tom escolhe o link mágico: os alunos têm todos um endereço fornecido pela escola, e «palavra-passe esquecida» teria-se tornado a segunda vida dele. Faz-te a mesma pergunta para a tua própria app: que método cria menos fricção para OS TEUS utilizadores? Não há uma boa resposta universal, apenas uma boa resposta para o teu público.

sequenceDiagram
  participant E as Aluno
  participant A as App do Tom
  participant S as Serviço Supabase
  E->>A: Escreve o seu endereço de email
  A->>S: Pede um link mágico
  S-->>E: Envia o email com o link
  E->>A: Clica no link recebido
  A-->>E: Sessão aberta e hábitos mostrados

Integrar a autenticação com a IA

O percurso cabe em três tempos: criar o teu projeto no Supabase (uma conta, um clique em «New project»), recuperar as tuas duas chaves de acesso, e depois pedir à IA que ligue tudo. Tal como na implementação do capítulo 5, não tens de memorizar o procedimento — pedes um acompanhamento passo a passo adaptado ao teu nível. Eis o prompt completo do Tom:

Quero adicionar contas de utilizador à minha app de acompanhamento de hábitos.
Contexto: app HTML/CSS/JS implementada na Vercel, dados em localStorage por enquanto.
Usa o Supabase Auth com login por link mágico, sem palavra-passe.
O que quero:
1. um ecrã de login simples: campo de email + botão «receber o meu link»
2. depois do clique no link recebido por email, o utilizador volta à app, ligado
3. um botão «terminar sessão» discreto no topo da página
4. se o utilizador não estiver ligado, vê o ecrã de login; senão, os seus hábitos
IMPORTANTE: não toques ainda nos dados — mantemos o localStorage por enquanto.
Guia-me primeiro para criar o projeto Supabase e encontrar as minhas duas chaves, passo a passo, antes de escrever uma única linha de código.

A linha «não toques ainda nos dados» é estratégica. Adicionar a autenticação E migrar os dados ao mesmo tempo são duas grandes mudanças de uma vez — exatamente o que o capítulo 4 te ensinou a evitar. Este capítulo liga o reconhecimento dos utilizadores; o capítulo 7 ocupar-se-á dos dados deles. Um degrau de cada vez, mesmo quando a escada é grande.

As chaves de API: os teus primeiros segredos

Ao criar o teu projeto Supabase, vais encontrar duas chaves. A chave pública (dita «anon») identifica a tua app: pode viver no código do navegador, foi feita para isso. A chave secreta (dita «service_role») dá TODOS os direitos sobre o teu projeto: nunca, mas nunca, deve aparecer em código visível por um navegador. Estes segredos arrumam-se num ficheiro especial, o .env, que o Git ignora:

# Ficheiro .env — fica na tua máquina, nunca publicado
SUPABASE_URL=https://oteuprojeto.supabase.co
SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIs...   # pública: OK no navegador
SUPABASE_SERVICE_ROLE_KEY=eyJzZXJ2aWNl...   # SECRETA: nunca no navegador

Testar o fluxo como um utilizador

A autenticação testa-se de ponta a ponta, sem atalhos: escreve um endereço verdadeiro, vai buscar o email (olha também no spam, é o bloqueio clássico), clica no link, verifica que chegas ligado. Depois termina a sessão e recomeça. Por fim, o teste decisivo: abre a app em dois navegadores diferentes com dois endereços diferentes, e verifica que cada um tem a sua própria sessão. Se algo encravar, aplica o método do capítulo 4 — relatório de bug em quatro pontos. Eis a versão adaptada à autenticação:

Bug de login a corrigir.
O que faço: escrevo o meu endereço, recebo o email do link mágico, clico no link.
O que esperava: voltar à app, ligado.
O que acontece: volto à app mas continuo a ver o ecrã de login.
Erro na consola: [cola aqui a linha vermelha exata, se existir]
Verifica em prioridade a configuração dos URL de redirecionamento no Supabase — o URL do meu site implementado é https://minha-app.vercel.app — e diz-me o que corrigir, passo a passo.

Este prompt mostra um reflexo de nível superior: o Tom orienta o diagnóstico («verifica em prioridade os URL de redirecionamento») porque é A causa clássica deste sintoma — o serviço reenvia o utilizador para um endereço que não corresponde ao site implementado. Não és obrigado a conhecer estas causas clássicas: pergunta à IA «quais são as três causas mais frequentes deste problema?» e ela lista-tas.

O que te espera no próximo capítulo

No fim desta etapa, a app do Tom reconhece cada aluno… mas os hábitos deles ainda vivem no localStorage de cada aparelho. A Lina pode ligar-se na biblioteca e no telemóvel, mas ainda não vê lá os mesmos dados. Falta a segunda metade da solução: uma base de dados online, onde os hábitos de cada conta serão guardados de uma vez por todas, acessíveis de qualquer lado. É todo o programa do capítulo 7 — e já assentaste a fundação ideal para a receber.