Configurações
Três categorias, e o conjunto é fechado. Cada uma é lida por código que conhece o formato dela,
então uma categoria desconhecida responde 404 em vez de criar uma linha nova.
| Categoria | Escopo | Guarda | Custa |
|---|---|---|---|
softswiss | Casino | URL do backend de provedor, token de auth e id de casino daquele casino | settings.read / settings.write |
webhook | Casino | O endpoint de resultado e o segredo de assinatura deles | settings.read / settings.write |
lobby | Plataforma | As três janelas de lobby | Super-usuário |
Configuração de e-mail não é uma categoria. Ela é construída durante a inicialização, então um documento salvo nunca alcançaria isso.
Segredos nunca voltam
Ler um documento responde "<campo>Set": true|false em vez do valor. O valor em si fica
selado em repouso.
Não limpa. O cliente não teria como ter recebido o segredo, então tratar campo ausente como "limpe isto" faria apertar Salvar apagar uma credencial que funciona.
Para trocar um segredo, digite o novo. Para deixar como está, deixe o campo vazio.
Grupos de credencial são tudo ou nada
Preencher a URL do backend e deixar o token de auth em branco é recusado na escrita, enquanto ainda há um operador presente para corrigir.
Meio configurado, aquele casino apresentaria a credencial da plataforma ao próprio endpoint, que é o vazamento que o agrupamento existe para evitar.
Salvamentos valem imediatamente
O resolvedor cacheia por 30 segundos mas invalida explicitamente no salvamento. Só com TTL, um salvamento ficaria invisível até a entrada expirar: o banco correto, o sistema em execução ainda na credencial antiga, e nada reportando erro.
A allowlist de jogos funciona igual. Ela é cacheada, mas invalidada explicitamente no salvamento, então uma mudança feita aqui vale na hora. Uma mudança feita fora do console pode levar até 30 segundos para aparecer. Veja Mudanças de allowlist.
softswiss
A credencial usada para emitir sessões demo para assentos de bot. É por casino, porque cada um tem o próprio id de casino e o próprio token.
Deixar vazio cai para as credenciais de ambiente da plataforma, o que significa que as sessões de bot são emitidas sob o seu id de casino, e não o deles. Isso é válido numa instalação de casino único e errado numa multi-tenant.
webhook
Para onde vão os resultados terminais daquele casino, e o segredo com que essas requisições são assinadas.
Um casino que resolve para nenhum endpoint é pulado, nunca redirecionado para o webhook da plataforma. O backend deles simplesmente nunca fica sabendo que uma batalha acabou, o que é silencioso do lado deles, então confirme isso no onboarding e não na virada para produção.
lobby, escopo de plataforma
As três janelas: quanto tempo um lobby aceita jogadores, quanto tempo uma batalha pode ficar iniciando, e quanto tempo uma execução pode levar.
Elas têm escopo de plataforma e são só de super-usuário, porque descrevem como esta instalação roda uma batalha, e não as credenciais de um casino, e o serviço de lobby é um só.
Valem a partir da próxima batalha, não do próximo deploy.
Um campo de formulário não tocado envia zero, e ler isso literalmente fecharia todo lobby no instante em que ele abrisse.
O formulário, o resolvedor e o serviço recusam zero como janela, cada um de forma independente.
O que não está aqui
max_inflight_battles dimensiona um canal uma vez, na construção. max_concurrent_users é
congelado no admissor no boot. O consumidor do stream do Redis é construído no boot e entra em
loop.
Guardar qualquer um deles produziria uma tela que salva e não muda nada. Mudá-los é um redeploy do lado da plataforma. Veja O que o host controla.