Headers & Autenticação de Sessão
Projetos sem autenticação usam apenas createHttpClient e adicionam HeaderStore e autenticação de sessão apenas quando necessário.
O código commonService.ts desta página é parte do arquivo completo.
O código abaixo de HeaderStore, headersProvider e sessionAuth não é um exemplo de arquivos independentes, mas explica partes do adaptador HTTP compartilhado do projeto (rxjsHttpService.ts/commonService.ts). Se você quiser ver a estrutura completa do arquivo, verifique o código completo do HTTP Client em sua forma mínima e expandida antes de ler esta página.
Cabeçalho compartilhado no navegador
Cabeçalhos que precisam ser usados por vários serviços, como o token de acesso recebido após o login,HeaderStorepodem ser armazenados em.
commonService.ts
tsNo Next.js, separe os cabeçalhos do navegador e do servidor.
O Componente do Cliente lê o HeaderStore, enquanto o Componente do Servidor lê os cookies. headersProviderpode ser criado. Nesta função, você pode separar a forma de consulta de headers entre CSR e SSR em um único lugar.
commonService.ts
tsSe 401 refresh for necessário, envolva uma vez com callApi.
Não modifique os serviços gerados automaticamente um a um, mas adicione um operador de sessão aocallApiserviço público. Assim, todos os serviços gerados usarão as mesmas regras de busca e refresh de token.
commonService.ts
tsSe não houver autorização, verifique primeiro o endpoint do token e, se a solicitação original for 401, faça uma nova solicitação após o refresh. Se o refresh também falhar, chame o endpoint de logout e passe o erro original.
Quando apenas a sincronização do token é necessária, sem refresh/retry.
Para sincronizar apenas o token antes da requisição sem usar refresh/retry 401, use withEnsureToken().
Se não precisar de autenticação,
APIs públicas ou projetos simples são suficientes. HeaderStore e autenticação de sessão não são estruturas obrigatórias.