Когда хост WOPI сообщает об ошибке «проверка подтверждения не удалась» или «недействительное подтверждение WOPI», сначала выясните, какая система зарегистрировала отказ. Если хост хранилища отклоняет подписанный запрос Collabora, проверьте пару «ключ подтверждения» и ответ обнаружения, прежде чем изменять списки разрешенных хостов WOPI или отключать проверки подтверждения. Для установки пакетов Collabora обычно генерирует пару ключей; для развертываний Docker, Kubernetes и многорепликационных развертываний пара должна быть предоставлена и сохранена согласованно.
Проверка подлинности WOPI использует подписанный запрос и открытый ключ, объявленный клиентом WOPI в метаданных обнаружения. Она отделена от списка доверенных хостов WOPI Collabora, проверки сертификата TLS и проверки токена доступа хоста хранения. Перегенерация ключа может помочь, если закрытый ключ отсутствует или не совпадает с объявленным открытым ключом, но может создать новое несоответствие, если изменяется только одна реплика или хост все еще имеет кэшированные данные обнаружения.
| Доказательства в журнале | Вероятное место для проверки |
|---|---|
| При получении запроса CheckFileInfo или другого запроса WOPI хост хранилища выдает сообщение «Недействительное подтверждение WOPI». | Ключ подтверждения Collabora, данные обнаружения хоста, восстановление URL-адреса или метка времени. |
| Collabora выдает сообщение «Неавторизованный хост WOPI» или «Нет допустимых хостов WOPI». | Конфигурация списка разрешенных хостов WOPI / домена, а не ключ подтверждения. |
| Ошибка: недействительный, просроченный токен или отказ в доступе без подтверждения. | Выданный хостом токен доступа, права доступа или срок действия токена |
Проверьте наличие одного неудачного запроса в журналах Collabora и на хосте хранения; один только индикатор загрузки в браузере не указывает на сбой подтверждения ключа.
Начните с наименее ресурсоемкого варианта. При установке на основе пакетов сначала проверьте существующие файлы ключей и журналы служб; в текущей документации Collabora указано, что установка пакетов RPM и Debian автоматически генерирует пару ключей подтверждения WOPI. Если эти файлы присутствуют и стабильны, их обычно не требуется менять.
| Развертывание | Рекомендуемое действие | Компромисс |
|---|---|---|
| Сервер с управлением одним пакетом | Сохраните сгенерированную пару ключей; исправляйте права доступа или генерируйте новые только в случае отсутствия или несоответствия. | Изменения незначительны, но проверьте версию пакета и настроенные пути. |
| Отдельный контейнер Docker | Создайте пару один раз и постоянно монтируйте её в контейнер. | Для работы coolwsd требуется постоянный том и корректный доступ для чтения. |
| Kubernetes или несколько реплик | В каждом экземпляре Collabora можно установить одну общую пару секретный ключ/ключ. | Согласованные подписи на всех репликах; ротация также должна обновлять представление обнаружения хоста. |
| URL хоста изменен за прокси-сервером. | Проверьте открытую схему, хост, путь и строку запроса, используемые для проверки подписи. | Более сложный способ, чем смена ключей, но позволяющий избежать ненужных изменений учетных данных. |
В руководстве Collabora версии 24.04 указано, что общедоступный образ Docker не включает пару «ключ подтверждения»; сгенерируйте её и постоянно монтируйте. Официальная диаграмма Helm поддерживает секреты с ключом подтверждения. Никогда не генерируйте отдельную пару для каждой реплики, иначе балансировка нагрузки может привести к периодическим сбоям.
coolwsd.xmlпути к ключу подтверждения и убедитесь, что доступны как закрытый, так и открытый ключи. Обычно они находятся в папке /etc/coolwsd/, но структура пакетов и контейнеров может отличаться. Никогда не вставляйте закрытый ключ в журналы, заявки или чат.sudo openssl pkey -in /etc/coolwsd/proof_key -pubout -outform DER | sha256sumи openssl pkey -pubin -in /etc/coolwsd/proof_key.pub -outform DER | sha256sum. Полученные хеши должны совпадать. Если ваши пути отличаются, замените их фактическими настроенными путями. Если закрытый ключ невозможно прочитать, исправьте права собственности и разрешения в соответствии с моделью безопасности сервиса; не делайте его доступным для чтения всем.sudo coolconfig generate-proof-keyместо установки соответствующей утилиты. Для Docker сгенерируйте пару в подходящем постоянном месте, затем смонтируйте оба файла туда, где их ожидает Collabora, и убедитесь, что процесс coolwsd может прочитать закрытый ключ. На управляемой платформе используйте поддерживаемый механизм Secret вместо ручного редактирования работающего пода.
Проверьте синхронизацию времени в обеих системах. Запросы подтверждения WOPI включают метку времени; хост может отклонить старую или выходящую за рамки временного окна метку времени. Убедитесь, что NTP или служба времени платформы работают исправно и что серверы сообщают корректное время UTC. Не ослабляйте проверку меток времени, чтобы обойти проблему с часами.
Далее проверьте публичный URL-адрес, используемый хостом для восстановления подписанного запроса. Подтверждение привязано к URL-адресу запроса, включая соответствующие параметры запроса, и спецификация WOPI требует, чтобы представление URL-адреса, используемое для проверки, соответствовало подписанной форме. Обратный прокси-сервер, завершающий HTTPS-соединение, может заставить приложение видеть внутренний HTTP-адрес, даже если Collabora подписала публичный HTTPS-адрес. Настройте заголовки доверенного прокси-сервера и параметры внешнего URL-адреса приложения в соответствии с официальными рекомендациями хоста WOPI; не переписывайте логику подтверждения и не удаляйте параметры запроса.
Если проверка подлинности завершается неудачей только после смены ключа, обновите механизм обнаружения и убедитесь, что все реплики Collabora используют один и тот же открытый ключ. Если неудача возникает только при запросах, проходящих через один прокси-сервер или одну реплику, сравните журналы и конфигурацию этого пути, а не выполняйте повторную смену ключа. Отключение проверки подлинности может ослабить проверку безопасности и не должно использоваться в качестве решения для производственной среды.
Успешное открытие документа подтверждает только этот путь; повторите проверку для каждого хоста WOPI и маршрута прокси, с которыми вы работаете.
Обнаруживайте причины сбоев подтверждения WOPI в Collabora, такие как несоответствие ключей, устаревшие данные обнаружения, смещение времени или изменения URL-адресов прокси-сервера, — без ослабления проверки.
Сбросьте масштаб браузера, протестируйте чистую сессию и определите, когда меню с некорректным размером требует обновления сервера Collabora.
Разверните Collabora CODE с помощью Docker, безопасно подключите его к Nextcloud Office и проверьте корректность редактирования документов с помощью практических проверок WOPI и прокси-сервера.
Временно переведите coolwsd в режим отладки, зафиксируйте одну неудачную попытку открытия и используйте последовательность логов для разделения проблем, связанных с WebSocket, WOPI, прокси и контейнерами.
Настройте вход в административную панель Collabora Online для Docker или Linux, перезапустите нужную службу и подтвердите новый пароль, не раскрывая его.
Прежде чем изменять настройки Collabora или перезапускать службу, выясните, откуда берется нагрузка на ЦП: от активных документов, простаивающих рабочих процессов или мощности сервера.
Проверьте, не ограничивает ли Docker использование Collabora CODE, безопасно увеличьте лимит памяти Compose и убедитесь, что запущенный контейнер получил новое ограничение.
Упростите работу с Collabora CODE, используя компактный или вложенный режим, а также элементы управления WOPI PostMessage, чтобы безопасно скрывать выбранные кнопки, команды и вкладки.
Настройте Nginx на обработку HTTPS для контейнера Collabora CODE, корректное перенаправление WebSockets и проверку общедоступной конечной точки без открытия порта 9980.
Устранение неполадок с клавиатурой мобильного браузера, скрывающей текст в Collabora Online, с помощью быстрых обходных путей и отдельных проверок для браузеров, встроенных WebView и страниц-хостов.
