0033 — Adota a tela de login da xadm-seguranca e renomeia o token de API¶

Status: Aprovado · Responsável: Gustavo Madruga · Atualizado em: 2026-09-10 · Decidido em: 2026-09-10

Contexto¶

Três normas da casa alcançaram este app ao mesmo tempo, na migração para a constituição 1.4.10:

A tela de login passou a ser da lib (ADR central 0032, xadm-seguranca 0.7.1). A frota tinha cinco login.jte com o mesmo mecanismo de auth copiado (Firebase, signInWithPopup, POST /login/callback com CSRF); um bug de auth custava cinco PRs. Este app tinha o dele em src/main/jte/login.jte.
Piso xadm-seguranca ≥ 0.7.2 (constituição 1.4.8). A 0.7.2 recusa o boot quando app.api-token está declarado e vazio. Abaixo dela, o par feature ligada + env ausente subia healthy e respondia 401 a tudo em /api/**, e o sintoma chegava horas depois como "a integração parou". Este app declara app.api-token (Bearer do POST /api/xls/processar).
Env de token nomeada pelo destino (seguranca): <APP>_API_TOKEN. API_BEARER_TOKEN (nomear pelo papel) é o anti-padrão citado nominalmente — o mesmo nome vira valores diferentes por servidor e não diz a direção.

Sobe xadm-seguranca 0.6.0 → 0.7.2 e apaga o login.jte local. A tela vem da lib (xadm/login.jte); aqui ficam só os cosméticos, em xadm.views.login.*, escolhidos para manter a tela que o usuário já conhecia: marca: true, a tagline "Um ERP Completo para sua empresa" e o rodapé "BI Transporte · Processador XLS". O título é derivado pela lib ("Login — BI Transporte").
Re-deriva o kit de UI (kit/layout.jte e custom-theme.css, verbatim do central) e adota o Bootstrap 5.3.8 vendorizado da casa em /css/ e /js/. A cópia local 5.3.3 em public/vendor/ era uma divergência consciente (air-gap, sem CDN); desde a constituição 1.4.0 a casa também vendoriza, então a divergência perdeu o motivo — e o passo 5 da migração da lib manda apagar a cópia própria. O SDK do Firebase segue no gstatic, de propósito (é da lib).
Libera /js/** nos três lugares que decidem o acesso a estático neste app: static-resources, intercept-url-map e a ViewWhitelist. Sem isso o bundle JS responde 401 — inclusive na tela de login, onde por definição não há sessão.
Renomeia API_BEARER_TOKEN → VANTROBA_XLS_API_TOKEN (o destino é este app, slug vantroba-xls). A property segue app.api-token, que é o que a lib valida. Sem janela de convivência dos dois nomes: o Micronaut não aninha placeholder (${A:${B}}), e a guarda do pipeline reprova o aninhamento — o rename é atômico.

Deploy da release que traz isto exige a env nova ANTES, nos dois recursos do Coolify (vantroba-xls-jar-pull e vantroba-xls-native-pull), com o mesmo valor da antiga. Sem ela, o BearerTokenGuard recusa o boot: o container novo não fica healthy, o rolling update não troca e o smoke pós-deploy (0029) reprova. É ruidoso de propósito. Depois do deploy verde, apague a API_BEARER_TOKEN antiga.
Quem chama a API não muda nada: o valor do token é o mesmo; só o nome da env no servidor mudou.
EstaticosDoKitTest trava a classe de defeito do item 3: lê os href/src do kit/layout.jte e da tela de login renderizada e exige 200 anônimo para cada um, com a segurança ligada; e confere que o tema traz as classes .xadm-login-* (tema velho + lib nova = marca sem estilo, e nenhum gate amarra os dois repos).
A tela de login deixa de ser código deste app: mudança de markup ou de fluxo de auth é PR na lib. O custo declarado pelo ADR central — o header da tela de login é duplicado do kit e pode divergir visualmente do header logado — vale aqui também.
Complementa a 0023 (adoção da lib) e a etapa 07 (login das views).