- Navios
- 23 de setembro de 2026 às 01:21 UTC
- Autor
- Kamo
- Enviar
- 168cc8a
CheckFileInfo foi o único endpoint WOPI que ambos compararam o token de acesso documento contra o caminho da solicitação e acesso ao vivo verificado novamente; GetFile, PutFile, PutRelativeFile, renomearFile e o bloqueio/desbloquear/refrescar/get-lock apenas substitui verificou a assinatura e expiração do token, em seguida, agiu sobre o que imgId mostrou até na URL. Um token cunhado por POST /api/docs/open/{imgId} para um documento a membro tinha legitimamente aberto poderia ler ou substituir qualquer outro documento em qualquer organização, editando o caminho, e poderia bloquear, desbloquear ou sondar o bloqueio de qualquer documento da mesma forma. O próprio token válido de um destinatário só de leitura poderia também substituir o documento diretamente, ignorando a bandeira UserCanWrite checkFileInfo já disse ao editor para aplicar o lado cliente. Cada endpoint WOPI agora requer o assunto JWT do token (o imgId O WopiTokenService assina na hora certa) para igualar o imgId do caminho, e Verifica novamente o DocumentService.canUserAccess (leituras: GetFile, GET LOCK) ou canUserWrite (escritas: PutFile, PutRelativeFile, RenomearFile, LOCK/UNLOCK/ REFRESH LOCK) contra a base de dados em vez de confiar nas reivindicações do token — o acesso pode ser revogado ou expirar após o token ser cunhado, então uma verificação ao vivo é estritamente mais forte do que uma reivindicação de permissão estática. Autenticada por memória negada As leituras/escritas do byte são agora gravadas através do DocumentAccessAuditor da mesma forma um token inválido já era. Novo teste: WopiControllerAccessTest (11 casos cobrindo todos os objetivos listados acima); verificação de mutação revertendo o WopiController muda localmente, que Fica com as 11 vermelhas e depois restaura. WopiControllerAuditTest e WopiEditSessionTest actualizados para redigir os controlos de acesso já exigidos, uma vez que os seus casos existentes Assumir uma chamada permitida.