Начните с системы, которая зарегистрировала сбой.
Сообщение «Проверка подтверждения WOPI не удалась» означает, что хост WOPI не смог проверить подписанный запрос от Collabora Online. В типичной конфигурации Nextcloud Office Nextcloud является хостом WOPI, а Collabora — клиентом WOPI: Collabora отправляет подписанный запрос, а хост проверяет его. Точная формулировка может различаться в зависимости от интеграции и версии, поэтому сначала определите, какой компонент отправил сообщение и какой запрос не удался.
Проверка подлинности представляет собой проверку безопасности, а не общий тест подключения. Она связывает запрос с токеном доступа, полным URL-адресом запроса и меткой времени, а затем подписывает эти данные закрытым ключом подтверждения Collabora. Хост проверяет подпись, используя открытый ключ подтверждения, опубликованный в XML-файле обнаружения Collabora. Определение протокола WOPI описывает подписываемые поля и заголовки.
Первое действие: воспроизведите ошибку один раз, запишите время, действие с файлом, HTTP-статус и идентификатор запроса или корреляции, затем проверьте журналы платформы хранения и Collabora coolwsdна наличие того же события. Не отправляйте токены доступа, заголовки подтверждения или закрытые ключи в заявку.
Таблица быстрой диагностики
| Доказательство | Вероятная область для осмотра | Следующее действие |
| Сбой начался после перегенерации или замены ключа подтверждения Collabora. | Обнаружение в кэшированном XML-файле на стороне хранилища или с несовпадающим ключом | Обновите обнаружение на хосте WOPI и убедитесь, что он видит открытый ключ активного экземпляра Collabora. |
| Сбои происходят только при выполнении некоторых запросов или периодически. | Наличие нескольких узлов Collabora с разными ключами подтверждения или несогласованный кэш обнаружения. | Сравните значения ключей подтверждения, опубликованные каждым узлом, и проверьте маршрутизацию балансировщика нагрузки. |
| Сбой происходит после изменения прокси-сервера, имени хоста или URL-адреса. | Для подписи и проверки используются разные URL-адреса запросов. | Сравните полный URL-адрес, по которому обращалась Collabora, с URL-адресом, который хост WOPI использует для проверки подтверждения. |
| Сбой происходит только на одном хосте или одном сетевом пути. | Настройка доступности, обратного прокси-сервера или списка разрешенных хостов. | Проверьте подключение в обоих направлениях и отдельно от проверки подтверждения проверьте список разрешенных хостов WOPI. |
| Отсутствуют недавние изменения конфигурации, и подтверждающая метка времени отклоняется. | Синхронизация часов или анализ временных меток/проверка актуальности | Проверьте время UTC и статус NTP на обеих системах; убедитесь в правильности интерпретации метки времени на хосте и допустимом сроке действия. |
1. Подтвердите, что обнаружение раскрывает текущий открытый ключ.
Collabora публикует информацию о своих возможностях WOPI и ключе подтверждения на конечной точке обнаружения. С компьютера, который может получить доступ к URL-адресу Collabora, используемому вашим сервером хранения, проверьте следующее:
curl -fsS https://office.example.com/hosting/discovery
Найдите в XML-файле элемент proof-keyс текущим значением valueи, если он присутствует, с тегом oldvalue. Не путайте этот общедоступный материал с закрытым ключом, хранящимся на сервере Collabora. Наиболее полезным будет сравнение с ответом обнаружения, полученным самим хостом WOPI, поскольку браузер или рабочая станция администратора могут получить другой ответ через DNS, прокси или кэш.
Подтверждено: интеграция Collabora с WOPI использует подтверждающие подписи, а открытый ключ становится доступен через механизм обнаружения. Действие: получите данные обнаружения с фактического хоста/контейнера, который проверяет запросы, затем подтвердите, что XML-код действителен и соответствует конечной точке Collabora, настроенной на платформе хранения. В руководстве по привязке Collabora к SharePoint описано поведение генерации и обнаружения ключа подтверждения.
2. Проверьте, существует ли закрытый ключ и доступен ли он для чтения.
В Collabora проверьте журнал запуска на наличие предупреждений о том, что файл ключа подтверждения отсутствует или недоступен для чтения. Служба Collabora должна иметь возможность прочитать закрытый ключ для подписи. Для пакетных развертываний путь к конфигурации и учетная запись службы могут различаться; проверьте настроенный каталог службы и точки монтирования томов контейнера, а не предполагайте путь к хосту.
В документации Collabora coolconfig generate-proof-keyописаны случаи, когда автоматическая настройка ключа не сработала. Не запускайте эту команду в качестве стандартной процедуры устранения неполадок в работающем кластере. Генерация нового ключа изменяет идентификатор подписи. Если хранилище по-прежнему доверяет старому ответу обнаружения, запросы могут продолжать завершаться с ошибкой, пока хост не обновит используемый открытый ключ.
sudo coolconfig generate-proof-key
Используйте эту команду только после подтверждения отсутствия или недействительности ключа и после планирования того, как каждый узел Collabora и хост WOPI будут получать соответствующую информацию о ключе. Затем следуйте описанной в вашем пакете или контейнере процедуре перезагрузки службы и повторно получите данные обнаружения из сетевого пути валидатора.
3. Проверьте наличие несоответствия ключей между узлами или кэшами.
Один сервер Collabora может работать, в то время как развертывание с балансировкой нагрузки может периодически давать сбои. Например, один узел может иметь недавно сгенерированный закрытый ключ, в то время как другой по-прежнему подписывает данные старым ключом; хост с кэшированными данными обнаружения может не доверять ни одному из них постоянно. Это зависит от типа развертывания, а не доказательство того, что каждая периодическая ошибка вызвана ротацией ключей.
Действие: выполните получение данных /hosting/discoveryчерез балансировщик нагрузки и напрямую с каждого бэкэнда, если это разрешено. Сравните значения открытых ключей и убедитесь, что кэш обнаружения хоста WOPI актуален. Если узлы намеренно используют разные ключи, убедитесь, что интеграция хранилища поддерживает такую топологию; в противном случае поддерживайте согласованность конфигурации ключа подтверждения во всем кластере. Обновление обнаружения должно использовать поддерживаемый механизм интеграции. Избегайте редактирования кэша базы данных или перезапуска несвязанных служб без подтверждения.
4. Сравните подписанный URL-адрес с URL-адресом, который проверяет хост.
Подтверждение включает в себя абсолютный URL-адрес запроса WOPI в верхнем регистре, а также токен и метку времени. Это делает актуальным перезапись URL-адресов. Обратный прокси-сервер может изменять внешне видимое имя хоста, схему, порт, путь или экранирование. Если Collabora подписывает запрос для одного URL-адреса, но хост WOPI восстанавливает другой URL-адрес для проверки, правильная подпись может выглядеть недействительной.
Действие: сопоставьте один неудачный запрос на уровне прокси-сервера и приложения. Сравните схему, имя хоста, указанный порт, путь и закодированные символы, обнаруженные валидатором, с URL-адресом, используемым в коде проверки подтверждения. Проверяйте обработку переадресованных хостов и протоколов только в том случае, если приложение использует эти заголовки. Сохраняйте реальный URL-адрес запроса; не «исправляйте» проблему, отключая проверку подписи или доверяя произвольным переадресованным заголовкам.
5. Проверка обработки меток времени и байтов.
Доказательство WOPI включает в себя X-WOPI-TimeStamp. В спецификации Microsoft WOPI этот заголовок представляет собой 64-битное целое число, измеряемое с интервалом в 100 наносекунд, начиная с 1 января 0001 года, а не метку времени Unix в секундах. Пользовательский валидатор, который интерпретирует его как секунды Unix, отбрасывает цифры, изменяет кодировку или неправильно формирует подписанные байты, может отклонить действительные запросы.
Одной из возможных причин, когда хост устанавливает временной интервал актуальности, является расхождение во времени, но точный допустимый диапазон зависит от используемой реализации проверки. В рекомендациях Microsoft для Microsoft 365 для веб-версии используется 20-минутная проверка возраста; не следует предполагать, что это значение применимо ко всем интеграциям с Collabora. Действие: проверьте синхронизацию NTP и время UTC в системах Collabora и хранения данных, затем изучите собственное правило установки временной метки хоста и код анализа.
Также проверьте побайтовую структуру, если вы используете собственный хост WOPI. Токен в кодировке UTF-8; длина указывается в байтах; URL-адрес — это полный абсолютный URL-адрес в верхнем регистре; а значение метки времени должно быть представлено точно так, как указано. Открытый ключ должен соответствовать закрытому ключу, используемому экземпляром Collabora, отправившим запрос.
6. Разделяйте ошибки подтверждения от ошибок в списках разрешенных серверов и ошибок TLS.
Список разрешенных хостов WOPI определяет, к каким хостам хранения Collabora может обращаться. Проверка TLS определяет, является ли сертификат сетевого узла доверенным. Проверка подтверждения проверяет подпись запроса WOPI. Эти элементы управления связаны с безопасной интеграцией, но они не взаимозаменяемы. Добавление хоста в список разрешенных не исправит несоответствие подписи; отключение проверок TLS не исправит устаревший открытый ключ подтверждения.
Для развертываний Nextcloud официальное руководство по устранению неполадок рекомендует проверить необходимые пути HTTP(S) в обоих направлениях, просмотреть журналы Nextcloud и Collabora, а также подтвердить наличие предупреждений в списках разрешенных хостов WOPI. Действие: следуйте категории ошибки в журнале. Проверьте конечную точку обнаружения и доступность сети отдельно от валидатора подтверждения. Не расширяйте список разрешенных в *качестве обходного пути.
Последовательность безопасного восстановления
- Зафиксируйте точное время сбоя запроса и определите, какая служба зарегистрировала ошибку проверки подтверждения.
- Проверьте журналы Collabora на наличие предупреждений об отсутствующих ключах; изучите XML-файл обнаружения из сетевого пути хоста WOPI.
- Сравните открытый ключ, полученный в процессе обнаружения, с закрытым ключом и конфигурацией узла, использованными для подписи запроса.
- Проверьте согласованность балансировщика нагрузки, кэширование обнаружения, а также любые недавние изменения ключей, имен хостов, прокси-серверов или TLS.
- Сравните URL-адрес подписанного запроса и обработку временной метки, не раскрывая токены или заголовки подтверждения.
- Повторите проверку с одним документом и подтвердите успешное выполнение того же запроса в журналах хоста, прежде чем восстанавливать нормальный трафик.
Если сбой сохраняется, соберите очищенные журналы с обеих сторон, укажите версии Collabora и хранилища, тип развертывания, задействован ли один или несколько узлов, XML-файл обнаружения с удаленными секретами и маршрут прокси для запроса, вызвавшего сбой. Передайте эту информацию соответствующему поставщику или разработчикам интеграции. Точная строка ошибки сама по себе не позволяет установить, является ли причиной устаревший механизм обнаружения, канонизация URL-адреса, проблема со временем или ошибка пользовательского валидатора; доказательства на уровне запроса определяют, какой путь следует выбрать.