deploy
51072c153e
Sem ele o Keycloak monta os links e o iss com o KC_HOSTNAME global (auth-plataforma), e os runtimes do tenant validam contra ATM_ISSUER, que o molde define como auth.athleticmap.com. Os dois tem de bater. Nao da para resolver so no KC_HOSTNAME porque ele e um so e a plataforma depende do valor antigo. Dai o frontendUrl por realm, que e para isto.
4.2 KiB
———————————————————————————————————————————————————————————————————————————== P5.4 — o realm de um tenant novo.
DERIVADO de tenants/plataforma/realm/athleticmap-realm.json, que e o realm
que existe hoje. Os nove papeis e o cliente spa sao os de la — NAO inventei
nenhum, e um papel a mais aqui seria um papel que nenhum codigo verifica.
── OS MARCADORES ───────────────────────────────────────────────────────────
{{REALM}} athleticmap-<N> — decidido em 2026-09-19
{{TENANT}} o nome comercial, que vira o subdominio
SAO COISAS DIFERENTES desde aquela decisao. O realm e numerado porque uma
instancia so de Keycloak nao comporta quatro realms chamados athleticmap; o
subdominio e o nome que o cliente ve.
── O DOMINIO DOS REDIRECTS ─────────────────────────────────────────────────
athleticmap.com, e nao athleticmap.influxdigital.com.br — o canonico foi
decidido em 2026-09-16 (P0.9). O tenant plataforma ainda usa o antigo porque
o corte de dominio nao aconteceu; um tenant NOVO ja nasce no certo.
Se o corte nao tiver acontecido quando o primeiro tenant for provisionado, ESTE arquivo precisa mudar junto — e o sintoma de esquecer e um login que redireciona para um host que nao resolve.
── NAO HA USUARIO AQUI ─────────────────────────────────────────────────────
O administrador do cliente e criado pela Admin API, DEPOIS do realm, porque ele
precisa de senha temporaria e de UPDATE_PASSWORD — e nenhum dos dois cabe num
arquivo versionado. Ver EtapaCriarRealm.
———————————————————————————————————————————————————————————————————————————==
— O SMTP, E POR QUE ELE VIVE AQUI ————————————————————————————————————
Quem manda o e-mail de boas-vindas e o PROPRIO KEYCLOAK, pela Admin API
(execute-actions-email), e nao o servico-captacao.
Isso tem tres consequencias boas:
- o nosso servico nao precisa de biblioteca de e-mail nem de configuracao de SMTP — uma dependencia a menos e um segredo a menos por onde vazar;
- o link de definicao de senha e gerado e assinado pelo proprio Keycloak, com validade propria. Nao ha token nosso a inventar, guardar nem expirar;
- "fechar a aba e voltar depois pelo link do e-mail" — criterio do card — funciona de graca, porque o link nao depende de sessao nenhuma.
A SENHA DO SMTP NAO FICA NESTE ARQUIVO. Os marcadores sao preenchidos em memoria,
no momento de criar o realm, a partir da configuracao do servico — o realm e
criado pela API, e nao commitado. Um {{SMTP_SENHA}} literal que chegasse ao
Gitea seria um segredo versionado, que e exatamente o que a regra do repositorio
proibe.
── O frontendUrl, E POR QUE ELE NAO E OPCIONAL ───────────────────────────
https://auth.athleticmap.com — o host de autenticacao DOS TENANTS.
Sem ele o Keycloak monta os links (e o iss do token) com o KC_HOSTNAME
global, que e auth-plataforma.athleticmap.com. E os runtimes do tenant
validam contra ATM_ISSUER, que o molde consolidado define como
https://auth.athleticmap.com/realms/{{REALM}}.
Os dois TEM de bater. Quando nao batiam, em 2026-09-24, o login do primeiro tenant provisionado morria antes de comecar: a SPA redirecionava para um host sem certificado e sem rota, e mesmo passando por cima o token seria recusado pelos runtimes.
Nao da para resolver so no KC_HOSTNAME porque ele e um so, e a plataforma
depende do valor antigo — os servicos dela estao configurados com
auth-plataforma. Dai o frontendUrl por realm, que e exatamente para isto.