Files
athletic-map-deploy/moldes/realm-do-tenant.LEIA-ME.md
T
deploy 51072c153e feat(molde): frontendUrl no realm do tenant
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.
2026-09-24 23:10:49 +00:00

72 lines
4.2 KiB
Markdown

———————————————————————————————————————————————————————————————————————————==
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:
1. 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;
2. 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;
3. "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.