Quando um host WOPI reporta “falha na validação da prova” ou “Prova WOPI inválida”, primeiro confirme qual sistema registrou a rejeição. Se o host de armazenamento estiver rejeitando a solicitação assinada do Collabora, verifique o par de chaves de prova e a resposta de descoberta antes de alterar as listas de permissões do host WOPI ou desativar as verificações de prova. Para instalações de pacotes, o Collabora normalmente gera o par de chaves; para implantações em Docker, Kubernetes e com múltiplas réplicas, o par deve ser fornecido e persistido de forma consistente.
A validação de prova WOPI utiliza uma solicitação assinada e a chave pública anunciada pelo cliente WOPI em seus metadados de descoberta. Ela é independente da lista de hosts WOPI confiáveis da Collabora, da validação de certificado TLS e da verificação do token de acesso do host de armazenamento. A regeneração da chave pode ajudar quando a chave privada está ausente ou não corresponde à chave pública anunciada, mas pode criar uma nova incompatibilidade se apenas uma réplica for alterada ou se um host ainda tiver dados de descoberta em cache.
| Evidências no registro | Área provável para verificar |
|---|---|
| O host de armazenamento exibe a mensagem “Comprovante WOPI inválido” ao receber uma solicitação CheckFileInfo ou outra solicitação WOPI. | Chave de prova da Collabora, dados de descoberta do host, reconstrução de URL ou carimbo de data/hora. |
| O Collabora exibe a mensagem “Host WOPI não autorizado” ou “Nenhum host WOPI aceitável”. | A lista de permissões de host/configuração de domínio do WOPI, não a chave de prova. |
| Token inválido, expirado ou acesso negado sem comprovação de erro. | Token de acesso emitido pelo host, permissões ou expiração do token |
Verifique uma solicitação com falha nos logs do Collabora e do host de armazenamento; apenas o indicador de carregamento do navegador não identifica uma falha na chave de prova.
Comece com a opção menos disruptiva. Em uma instalação baseada em pacotes, verifique primeiro os arquivos de chave e os registros de serviço existentes; a documentação atual do Collabora afirma que as instalações de pacotes RPM e Debian geram automaticamente um par de chaves à prova de WOPI. Se esses arquivos estiverem presentes e estáveis, geralmente não é necessário rotacioná-los.
| Implantação | Ação recomendada | Troca |
|---|---|---|
| Servidor gerenciado por pacote único | Guarde o par de chaves gerado; repare as permissões ou regenere-as somente se estiverem faltando ou forem incompatíveis. | Alteração mínima, mas verifique a versão do seu pacote e os caminhos configurados. |
| Contêiner Docker único | Gere um par uma única vez e monte-o permanentemente no contêiner. | Requer um volume persistente e permissão de leitura correta para o coolwsd. |
| Kubernetes ou múltiplas réplicas | Monte um par de chave/segredo compartilhado em cada instância do Collabora. | Assinaturas consistentes entre as réplicas; a rotação também deve atualizar a visão de descoberta do host. |
| O URL do host foi alterado por trás de um proxy. | Verifique o esquema público, o host, o caminho e a string de consulta usados para a validação da assinatura. | Mais complexo do que a rotação de chaves, mas evita alterações desnecessárias de credenciais. |
O manual da Collabora versão 24.04 afirma que a imagem Docker pública não inclui um par de chaves de prova; gere um e monte-o de forma persistente. O gráfico Helm oficial suporta segredos com chaves de prova. Nunca gere um par separado para cada réplica, pois o balanceamento de carga pode tornar as falhas intermitentes.
coolwsd.xmlconfigurações do caminho da chave de prova e verifique se as chaves privada e pública estão disponíveis. Os locais comuns são em /etc/coolwsd/, mas os layouts de pacotes e contêineres podem variar. Nunca cole a chave privada em logs, tickets ou chats.sudo openssl pkey -in /etc/coolwsd/proof_key -pubout -outform DER | sha256sume openssl pkey -pubin -in /etc/coolwsd/proof_key.pub -outform DER | sha256sum. Os hashes resultantes devem corresponder. Se os seus caminhos forem diferentes, substitua-os pelos caminhos configurados reais. Se a chave privada não puder ser lida, corrija a propriedade e as permissões de acordo com o modelo de segurança do serviço; não a torne legível para todos.sudo coolconfig generate-proof-keyo utilitário instalado no diretório correspondente. Para Docker, gere o par em um local persistente apropriado, monte ambos os arquivos onde o Collabora os espera e certifique-se de que o processo coolwsd possa ler a chave privada. Em uma plataforma gerenciada, use o mecanismo Secret compatível em vez de editar manualmente um pod em execução.
Verifique a sincronização de tempo em ambos os sistemas. As solicitações de prova WOPI incluem um carimbo de data/hora; um host pode rejeitar um carimbo de data/hora antigo ou fora da janela de tempo. Confirme se o NTP ou o serviço de tempo da plataforma está funcionando corretamente e se os servidores reportam horários UTC válidos. Não flexibilize as verificações de carimbo de data/hora para contornar um problema de relógio.
Em seguida, inspecione o URL público que o host usa para reconstruir a solicitação assinada. A prova está vinculada ao URL da solicitação, incluindo os parâmetros de consulta relevantes, e a especificação WOPI exige que a representação do URL usada para validação corresponda ao formulário assinado. Um proxy reverso que encerra o HTTPS pode fazer com que o aplicativo veja um URL HTTP interno, mesmo que a Collabora tenha assinado o URL HTTPS público. Configure os cabeçalhos de proxy confiáveis e as configurações de URL externo do aplicativo de acordo com as orientações oficiais do host WOPI; não reescreva a lógica de prova nem remova os parâmetros de consulta.
Se a validação falhar somente após uma rotação de chave, atualize a descoberta e verifique se todas as réplicas do Collabora expõem a mesma chave pública. Se apenas as solicitações roteadas por meio de um proxy ou uma réplica falharem, compare os logs e a configuração desse caminho em vez de rotacionar a chave novamente. Desativar a validação de provas pode enfraquecer uma verificação de segurança e não deve ser usado como uma solução em produção.
A abertura bem-sucedida de um documento verifica apenas esse caminho; repita a verificação para cada host WOPI e rota de proxy que você opera.
Rastreie falhas na validação WOPI do Collabora devido a chaves incompatíveis, dados de descoberta desatualizados, desvio de relógio ou alterações de URL de proxy, sem comprometer a validação.
Redefina o zoom do navegador, teste uma sessão limpa e identifique quando um menu de tamanho malformado precisa de uma atualização do servidor Collabora.
Implante o Collabora CODE com Docker, conecte-o com segurança ao Nextcloud Office e verifique a edição de documentos com verificações práticas de WOPI e proxy.
Aumente temporariamente o nível de privilégios do coolwsd para depuração, capture uma falha de abertura e use a sequência de logs para separar problemas relacionados a WebSocket, WOPI, proxy e contêiner.
Configure o login de administrador do Collabora Online para Docker ou Linux, reinicie o serviço correto e verifique a nova senha sem expô-la.
Antes de alterar as configurações do Collabora ou reiniciar o serviço, verifique se a carga da CPU provém de documentos ativos, processos de trabalho ociosos ou da capacidade do servidor.
Verifique se o Docker está limitando o Collabora CODE, aumente o limite de memória do Compose com segurança e confirme se o contêiner em execução recebeu o novo limite.
Simplifique o Collabora CODE com o modo Compacto ou com Abas e os controles WOPI PostMessage para ocultar botões, comandos e abas selecionados com segurança.
Configure o Nginx para gerenciar o HTTPS em um contêiner do Collabora CODE, encaminhe corretamente os WebSockets de edição e verifique o endpoint público sem expor a porta 9980.
Solucione problemas com o teclado do navegador móvel que cobre o texto no Collabora Online, com soluções alternativas rápidas e verificações separadas para navegadores, WebViews incorporados e páginas de hospedagem.
