deploy
d68cf37493
O dominio athleticmap.com tem MX na Hostinger e SPF que so autoriza a Hostinger. A credencial foi medida: aceita em smtp.hostinger.com:587, recusada com 535 no Gmail e no Titan. O molde do realm nunca tinha sido empurrado — PROVISIONAMENTO_REALM_TEMPLATE estava vazio, e a etapa REALM_CRIADO teria parado nele logo depois do SMTP.
3.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.