triad-identity
Conta, sessão e capacidades · Lua 5.4
Endereço de rede está na lista de identificadores rejeitados, com o motivo escrito ao lado.
- Lua
- 2.318 linhas
- Superfície pública
- 8 exports
- Estados de sessão
- explícitos
não existe "quase pronto"
- Checagem de capacidade
- em memória
nunca toca no banco
Fonte verificada no repositório interno em 08/09/2026
O que faz
Em uso
É daqui que os outros domínios perguntam quem é o jogador e o que ele pode fazer. Nenhum consumidor recebe a tabela de sessão inteira, e nada do interior escapa pela API.
A identidade tem regras duras e escritas: o identificador da conexão nunca é identidade; nenhum identificador vindo do cliente é aceito; contas de terceiros servem para reconhecer, nunca para ancorar; e endereço de rede está explicitamente na lista de rejeitados, com o motivo ao lado, no lugar exato onde alguém o acrescentaria por engano.
A escolha de personagem é do servidor: ele manda a lista e valida a escolha, e a interface apenas apresenta. É o que torna a decisão do runtime de interface reversível sem custo.
Evidência
Como o sistema aparece
Capturas da interface real, renderizada com payload de demonstração derivado dos contratos do resource — organizações, cargos, pessoas e identificadores são sintéticos. Onde não existe interface, entra visualização técnica, rotulada como tal.
Visualização técnica O ciclo de uma sessão, e os dois lugares onde a decisão de projeto é dura: identidade e leitura.
Por dentro da engenharia
Decisões de implementação
Um bloco por decisão de implementação. Abra o que interessa.
Estados explícitos de sessão
Problema
Uma sessão que já tem conta mas ainda não terminou de carregar personagem é a origem clássica de bug fantasma: um sistema pergunta cedo demais, recebe um identificador incompleto e grava dado no lugar errado.
Solução
A consulta devolve nulo enquanto a sessão não estiver efetivamente em jogo. O estado é explícito e a transição é do servidor.
Por que foi feito assim
Um estado intermediário que responde como se estivesse pronto é pior que um erro: ele produz dado plausível e errado.
API retorna cópias imutáveis
Problema
Devolver a estrutura interna da sessão por referência deixa qualquer consumidor mutar o estado do dono. É a classe de defeito que faz dois jogadores acabarem compartilhando a mesma tabela em memória sem que nenhum código tenha pedido isso.
Solução
A API devolve cópia com os campos que o consumidor precisa. Trocar a estrutura interna não quebra ninguém, e ninguém consegue escrever nela.
Por que foi feito assim
Referência viva é acoplamento e é bug de concorrência ao mesmo tempo. Cópia custa uma alocação e remove as duas classes de problema.
Capacidade é operação de memória
Problema
Checar permissão com uma consulta ao banco a cada verificação é comum nas bases existentes. Contra um orçamento medido de cerca de 2.200 leituras por segundo, só isso consumiria o banco.
Solução
As capacidades da sessão ficam em memória e a checagem não toca no banco. Existe também a variante que responde várias de uma vez, porque atravessar fronteira de resource custa 38 microssegundos e perguntar cinco coisas em cinco chamadas custa cinco vezes isso.
Por que foi feito assim
Permissão é consultada em todo lugar. O que é consultado em todo lugar precisa ser barato, ou vira o gargalo do servidor inteiro.
Stack
O que foi usado
Runtime
- Lua 5.4
- CfxLua
Dados
- MariaDB
- Migration própria de identidade
Testes
- Identificadores
- Estados de sessão
- Direitos
- Integração com banco