Autenticação, autorização e DAL

02

Prepare-se — O que você vai construir

• Explicar identidade verificada sem depender de uma receita decorada.
• Relacionar permissão por recurso ao contrato e ao fluxo observável.
• Aplicar Data Access Layer em um caso real e em um limite.

Se precisar de apoio, consulte a capítulo anterior e volte a estas tarefas. Não há obrigação de seguir um prazo.

03

Entenda — Modelo mental e estrutura

1. Comece pelo modelo mental

Autenticação identifica; autorização decide acesso ao recurso. Uma DAL server-only centraliza consulta, revalida sessão e retorna DTO mínimo. Checks de layout ou UI não protegem ações diretas. Em identidade verificada, a sintaxe é apenas a superfície de um contrato. Relacione essa ideia a permissão por recurso e Data Access Layer antes de editar o exemplo. Em software real, uma linha pode compilar e ainda representar uma suposição incorreta sobre dados, tempo, ambiente ou responsabilidade. Por isso, descreva a entrada, a transformação e o resultado observável com palavras simples.

Descreva primeiro o contrato de identidade verificada e como ele se relaciona com permissão por recurso. Implemente a menor versão que revele o mecanismo e mantenha o caminho principal fácil de seguir. Se a solução depende de estado implícito, conversão silenciosa ou ordem acidental, registre essa dependência e procure torná-la explícita. O objetivo não é memorizar uma receita: é reconhecer quando o conceito se aplica, escolher uma abstração proporcional e conseguir explicar o custo dessa escolha.

2. Leia o código como uma sequência de decisões

import 'server-only';
export async function editarProjeto(actorId: string, projetoId: string, patch: Patch) {
  const projeto = await db.projeto.findUnique({ where: { id: projetoId } });
  if (!projeto || projeto.ownerId !== actorId) throw new ForbiddenError();
  return db.projeto.update({ where: { id: projetoId }, data: patch });
}

Leia o exemplo de fora para dentro. Primeiro localize os dados e o contrato público; depois acompanhe as transformações; por fim, identifique efeitos, falhas e saídas. O trecho deixa identidade verificada visível no código e permite evoluir Data Access Layer sem esconder o fluxo principal. Digite o trecho em vez de apenas copiá-lo. Troque nomes e valores, faça uma hipótese e execute novamente. Essa comparação mostra o que pertence à regra da linguagem ou do framework e o que existe apenas por causa do exemplo.

Observe também o que o código não garante. Next.js organiza renderização, rotas, dados e entrega; React descreve a interface; autorização e integridade permanecem responsabilidades explícitas do código de servidor. Um tipo estático não valida automaticamente uma resposta externa; um componente não substitui semântica; uma abstração não corrige um contrato mal definido. Comentários úteis registram intenção, limite ou motivo. Comentários que repetem a sintaxe não compensam nomes vagos ou responsabilidades misturadas.

3. Converta observação em critério verificável

Uma solução forte torna identidade verificada legível, verifica permissão por recurso com evidência e registra os limites de Data Access Layer. Um bom critério descreve contexto, ação e resultado. Em vez de “funcionou”, registre qual entrada foi usada, qual saída era esperada e como uma falha deveria aparecer. Inspecione valores, mensagens e transições no Next.js 16.3.4, React 19.2, TypeScript e navegador. Quando houver interface, percorra também com teclado, zoom e tecnologia assistiva; quando houver servidor ou compilação, confira logs, tipos e limites de confiança.

A armadilha central é: transportar uma convenção antiga ou marcar tudo como cliente para contornar o contrato de identidade verificada.. Corrija a causa antes de empilhar exceções. Reduza o caso, reproduza o problema, altere uma variável por vez e repita o teste. Ao terminar, você deve conseguir dizer por que a solução funciona, quais suposições preserva, onde pode falhar e que evidência outra pessoa pode usar para revisar a entrega.

05

Construa — Teste cada decisão no ambiente

Crie um laboratório pequeno e executável em Next.js 16.3.4, React 19.2, TypeScript e navegador. Reproduza o exemplo, explique cada etapa e crie uma segunda versão que aplique Data Access Layer sem perder identidade verificada. Primeiro implemente o caminho principal sem abstrações prematuras. Depois use o depurador, o verificador de tipos, os testes ou as ferramentas de inspeção adequadas para confirmar o fluxo. Por último, force três situações adversas: entrada vazia, volume maior que o esperado e falha controlada em Next.js 16.3.4, React 19.2, TypeScript e navegador.

Não corrija todos os sintomas de uma vez. Para cada falha, anote hipótese, evidência e menor mudança. Rode novamente os cenários já aprovados para detectar regressões. Quando houver mais de uma solução possível, escolha pela clareza do contrato, pela facilidade de teste e pelo custo de mudança. Uma captura ou um log ajuda a documentar, mas código, critérios e testes reproduzíveis continuam sendo a fonte principal da entrega.

06

Pratique — Seis decisões de implementação

Resolva primeiro pelo raciocínio. Consultar o capítulo e testar hipóteses no navegador faz parte do processo; depois, releia as justificativas.

08

Projete — Implemente, compare e refine

Entrega incremental: um laboratório Next.js sobre autenticação, autorização e dal com rota executável, tipos gerados e estados verificáveis. Comece descrevendo, em até cinco linhas, quem usa o recurso e qual tarefa precisa concluir. Separe domínio, entrada e apresentação conforme a escala do problema. Inclua um caso real, um limite e uma falha recuperável. Ao final, escreva uma nota técnica explicando onde aplicou identidade verificada, como verificou permissão por recurso e qual limite encontrou em Data Access Layer.

import 'server-only';
export async function editarProjeto(actorId: string, projetoId: string, patch: Patch) {
  const projeto = await db.projeto.findUnique({ where: { id: projetoId } });
  if (!projeto || projeto.ownerId !== actorId) throw new ForbiddenError();
  return db.projeto.update({ where: { id: projetoId }, data: patch });
}

Critérios para revisar

• O contrato de identidade verificada está explícito, permissão por recurso foi exercitado e a falha de Data Access Layer produz um estado compreensível.
• Manter nomes, estados, foco e mensagens compreensíveis quando identidade verificada chegar à interface.
• O código evidencia identidade verificada e permissão por recurso sem estado acidental.
• A nota técnica registra o teste de entrada vazia, volume maior que o esperado e falha controlada em Next.js 16.3.4, React 19.2, TypeScript e navegador.

09

Retome — Organize sua revisão

• Explique com suas palavras a relação entre identidade verificada e permissão por recurso.
• Reabra o laboratório sem consultar o texto e reconstrua a decisão ligada a Data Access Layer.
• Aplique o teste “Executar o caminho principal e os limites de permissão por recurso, observando o resultado de Data Access Layer.” ao projeto acumulado e registre uma melhoria.

Feche a explicação, tente lembrar um exemplo e depois confira. Retome uma dificuldade no próximo encontro e alguns dias depois; ajuste o intervalo ao que ainda precisa praticar.

Use exemplos concretos na autoavaliação: “consigo explicar com consulta” ou “quero praticar novamente”. Marcar como lida não representa uma certificação.