CASE DE EVIDÊNCIA
Hardening da autorização de credenciais de voz em Spaces
Um hardening real de autorização no PING moveu a validação de membership ativa do Space para o próprio trust boundary de credenciais de mídia e depois corrigiu um double legado do teste de advisory lock sem nova alteração de produção.
01
Problema
O emissor de credenciais de voz em Spaces dependia demais de um claim upstream de entrada. Fazer a própria fronteira de credenciais comprovar que o usuário ainda é membro ativo do Space associado ao canal de voz, preservando os comportamentos já estabelecidos para Server e DM.
02
Métodos aplicados
- 01Seleção de Métodos de TrabalhoEvita excesso e sobreposição de skills, preservando ownership claro entre descoberta, implementação, verificação, revisão e entrega.
- 02Revisão de Segurança de APIsEncontra falhas específicas de APIs que uma revisão web genérica costuma perder, especialmente violações de autorização e invariantes de negócio.
- 03Construção de Testes de RegressãoTorna correções de bugs duráveis e prova que o novo teste realmente detecta o defeito em vez de apenas passar junto com a correção.
- 04Teste de Limites de IntegraçãoEncontra defeitos de serialização, persistência, protocolo e modos de falha que mocks e testes unitários isolados não conseguem provar.
- 05Entrega de Mudanças com GitHub e VercelConduz mudanças do repositório à revisão e à entrega sem misturar trabalhos alheios, duplicar pull requests ou exagerar a prontidão do deploy.
Registro de decisões
- 01
Colocar a autorização na fronteira de credenciais
Resolver o canal de voz até seu Space e exigir um registro SpaceMember ativo antes de emitir credenciais de mídia, em vez de tratar o claim upstream de entrada como prova suficiente.
- 02
Provar primeiro o caminho não autorizado
Codificar o claim de membership ausente ou desatualizada como uma regressão RED deliberada antes de alterar o código de produção.
- 03
Diagnosticar separadamente a falha pós-merge
Quando a main expôs um fake desatualizado da transação do advisory lock, manter o fix de segurança intacto e corrigir somente o double de teste que já não representava o contrato da fronteira de credenciais.
- 04
Verificar o merge final na main
Contar o case apenas depois do follow-up somente de testes ser integrado e o workflow canônico da main passar testes, formatação, lint, typecheck e build no commit final de merge.
03
Verificação
Trate este relatório como evidência dos métodos e da verificação mostrados aqui. A sobreposição com um pack, sozinha, não prova que o pack foi usado ou validado por completo.
04
Resultado
- 01
A emissão de credenciais de voz em Spaces agora verifica de forma independente a membership ativa no Space associado ao canal.
- 02
A regressão de segurança saiu de RED deliberado para GREEN mantendo cobertos os comportamentos existentes de credenciais para Server e DM.
- 03
A única falha pós-merge foi isolada em um double legado do teste de advisory lock e corrigida em um follow-up somente de testes, sem nova alteração de produção.
- 04
O workflow final da main passou testes, formatação, lint, typecheck e build antes deste case ser registrado.