- Navios
- 5 de setembro de 2026 às 07:25 UTC
- Autor
- Kamo
- Enviar
- 5355b88
Dois defeitos nos terminais /settings/integrations/member, ambos vivos e ambos Atingível por qualquer membro subscrito. O ID era o único controle de acesso. Cada endpoint /member/ {id} tomou o integração id diretamente do caminho e não perguntou mais nada, para que um membro pudesse atualizar a linha de outro membro -- incluindo sobrescrever as credenciais nele -- apagar, testar ou publicar um gatilho de sincronização para ele. Um UUID não é um verificação de autorização: IDs viajar em logs, threads de suporte e histórico do navegador, e A linha endereçada contém uma credencial de correio. Agora, os membros são todos quatro, respondendo 404 em vez de 403 de modo que abordar a linha de outra pessoa faz não confirmar que existe, e registrar a tentativa porque um real é Cliente avariado ou alguém a andar. Uma linha de nível ORG é de propriedade de ninguém e assim nunca é de um membro próprio, o que importa porque essa é a linha que detém o todo Organização OAuth Grant. E as respostas dos membros ainda devolveram a entidade. cbc238a tomou credenciaisJson fora dos dois objetivos ORG e deixou os quatro membros retornando-o, que é a mesma bolha criptografada nos mesmos corpos de resposta, caches de navegador e logs proxy -- apenas nos caminhos que não tinha visto. Todos os quatro passam pela mesma vista agora, informando apenas se uma credencial está em arquivo. A tela que chama estes é inacessível hoje (nada importa PersonalProviderSection, e pede um GET /member/{id} que não está mapeado), de modo que nenhum defeito estava sendo exercido. Essa não é uma razão para deixar qualquer um deles: os endpoints são mapeados, autenticados e servidos.