O que essa API protege, e o que não protege
O que essa API protege, e o que não protege
Pergunta: "o que essa API me protege, e o que ela não protege?"
Credencial de transporte (host e guest)
credential é uma string opaca, obrigatória nas duas pontas (createHost/joinRoom), nunca decodificada por esta lib. O nome é neutro por decisão — não apiKey, não token — justamente para não prometer validação que a lib não faz.
Quem valida a credencial de fato depende de onde o servidor está implantado, e a lib não tem como saber isso nem declarar isso. No deploy pretendido, o caminho do guest passa pelo gateway (PWA → gateway → rede interna), então a credencial é validada ali. Fora desse perímetro, não é. A lib não sabe em qual dos dois casos está — e não existe flag para declarar isso. É a única coisa que impede alguém (integrador ou agente) de ler "credencial obrigatória" como "logo está protegido": ela é obrigatória para o transporte, não é prova de autorização.
x-api-key está depreciada
Nenhuma página desta documentação explica como usá-la — se aparecer em algum lugar, é só na lista do que morreu.
A lista de limites, junto (não espalhada em outras páginas)
| mecanismo | o que protege | o que NÃO protege |
|---|---|---|
login (credential obrigatória) | reduz quem pode tentar — precisa ter conta | não é autorização de sala. Credencial é de conta, não escopada por sala: qualquer conta logada que tenha o joinCode ou o link ainda entra. Estar logado ≠ estar autorizado àquela sala específica. |
approval_and_code (recomendado para o caso do microfone, não exigido pela API) | barreira humana (aprovação) + código não público, juntos — open/code sozinhos não têm barreira contra um terceiro entrando em paralelo | displayName é auto-declarado, nunca verificado — não distingue um impostor de um guest legítimo na janela de espera. Aprovar o guest certo não impede aprovar um segundo guest também (multi-guest concorrente é suportado, sem promessa extra — ver abaixo). room.onJoinRequest notifica o host; room.approveJoin(requestId)/room.rejectJoin(requestId) decidem o pedido — ver receita-microfone.md. |
maxGuests (⚠️ requer servidor com suporte a max_guests — ainda não entregue; ver pacote-plataforma.md A4 no repo de spec) | limita quantidade de guests admitidos | não decide identidade. Não impede um impostor de chegar antes do guest legítimo — só limita quantos entram no total. Não substitui a decisão humana da aprovação, e não decide quem, dentre N aceitos, é o guest certo. |
Multi-guest concorrente
Suportado, sem promessa extra: a lib não fixa origem, não dá um handle por guest, e não ordena nada entre eles. Quem usa approval com N > 1 decide manualmente, caso a caso, quem aprovar — a lib não ajuda a distinguir.
Custo da forma opaca (Standard Schema / payload<T>())
Declarar um evento como Standard Schema ou via payload<T>() (ver eventos.md) faz o fingerprint do handshake comparar só o nome daquele evento, não a forma concreta — quem escolhe essas camadas abre mão da rede de proteção do fingerprint para aquele evento especificamente. É uma fraqueza invisível enquanto não se olha o resultado do handshake como dado (ver eventos.md); a mitigação é justamente expor esse resultado como valor consultável em runtime, não escondê-lo em log.
Dependência de perímetro, sem flag para declarar
Resumo da seção de credencial acima, porque é a mais fácil de esquecer: a segurança real desta API depende do perímetro de rede em que o serviço está implantado — gateway na frente do caminho do guest, ou não — e a lib não verifica isso em runtime, não tem como, e não existe um parâmetro para o integrador declarar "estou atrás do gateway". Documentar essa dependência aqui é a mitigação; não existe mitigação em código para isso.
Last updated on