Segurança & tenant

Como o resource autentica o painel, isola tenants e qual o threat model.

Camada 1 — Bearer token

Toda request HTTP precisa do header de autorização:

http

Authorization: Bearer <Config.ServerLinkToken>

Aceita-se também x-api-key: <token> como fallback para integrações legadas — comportamento idêntico, mesma comparação constant-time. Tokens diferentes do configurado retornam 401.

server/main.lua·lua

local function resolveLinkToken(req)
  local h = req.headers["authorization"] or req.headers["Authorization"]
  if type(h) == "string" then
    local bearer = h:match("^[Bb]earer%s+(%S+)%s*$")
    if bearer and bearer ~= "" then return bearer end
  end
  return req.headers["x-api-key"]
end

Camada 2 — tenant slug

Além do token, toda request exige o header:

http

x-tenant-id: <Config.TenantSlug>

Se o header faltar ou não bater com Config.TenantSlug, o resource retorna 400 mesmo com token válido. Isso impede que um token vazado seja usado contra outro tenant (defesa em profundidade).

Por que dois headers?

Token sozinho é suficiente para auth, mas o slug funciona como second factor: ao reemitir tokens (ex.: ao mudar de slug no painel) a transição é controlada explicitamente.

Camada 3 — slug embutido no JWT

No painel, o JWT de acesso inclui tenantId + tenantSlug. O middleware do Nest compara contra o tenant carregado do banco — token com slug "antigo" cai em Token tenant mismatch e exige refresh.

Quando você muda o slug em Configurações → Branding, o backend revoga todas as sessões e reemite tokens novos para a sessão atual. Outros dispositivos vão para login.

Threat model

Token vazado — atacante consegue ler dados desse tenant específico (não outros). Mitigação: rotacione o serverLinkToken via painel.
Servidor FX comprometido — o atacante já tem acesso ao banco completo. O resource Lua só expõe o que o banco já tem; não há escalada de privilégio.
Painel comprometido — atacante consegue ler tenants que tem JWT válido. AuditLog registra toda mudança relevante; pode usar para forensics.
Sniffer na rede — coloque o FXServer atrás de HTTPS (NGINX/Caddy fazendo TLS termination na frente da porta 30120).

HTTPS é seu trabalho

O FXServer expõe HTTP puro na 30120. Use um reverse proxy (NGINX / Caddy / Traefik) com TLS antes de expor pra internet.

Permissões no painel

Cada tenant tem cargos (Role) com permissões granulares. Cargos padrão criados no register:

Owner — recebe todas as permissões.

Permissões existentes:

users.ban · users.unban
economy.reset
staff.manage
branding.edit
garage.edit · inventory.view
analytics.view · logs.view
modules.manage

Auditoria

Toda ação administrativa relevante (mudança de branding, ban, mudança de permissão) entra na tabela AuditLog. O Live Feed do painel mescla esses eventos com os do FXServer em ordem cronológica.

Anteriorconfig.lua Próxima Troubleshooting