ONLYOFFICE Docs 10.0: что меняется в готовой интеграции

После обновления ONLYOFFICE Docs до 10.0 недостаточно открыть документ в редакторе. Серверные операции конвертации и Document Builder, правила WOPI и доступ через прокси требуют отдельных проверок. Интеграция может успешно показать файл и при этом не завершить следующую операцию вашего документооборота.

Что считать событием, а что пояснением к нему

Changelog ONLYOFFICE Docs датирует выпуск 10.0.0 десятым октября 2026 года. Обзор для разработчиков опубликован 21 октября. Это дата последующего объяснения изменений, а не основание переносить выпуск на другой день.

Разбирать обновление полезнее от пути документа. Пользователь выбирает файл, редактор его открывает, сервер выполняет нужную операцию, результат возвращается в бизнес-систему. У каждого участка своё подтверждение. Если приёмка заканчивается первым экраном, остальные участки остаются непроверенными независимо от числа новых функций в релизе.

Токен редактора больше не подходит на любую операцию

Changelog сообщает, что /converter, /docbuilder и /command больше не принимают токен из конфигурации редактора. Для этих запросов поле operation в токене опционально, а для /converter/from-file и /docbuilder/from-file — обязательно. Нельзя сокращать это правило до «operation теперь обязателен везде» или «старый токен подходит, если файл открылся».

Составьте перечень фактических серверных вызовов своего приложения. Для каждого нужны назначение, вызывающая система, ожидаемый результат и применимая авторизация. Не помещайте рабочие секреты в такую ведомость. Для обсуждения архитектуры достаточно описать происхождение полномочий, не передавая сами значения.

Матрица проверки готовой интеграции

Последняя строка — наш критерий прикладной приёмки, а не новая функция ONLYOFFICE. Пользователь заказывает результат в своей системе. Технически успешный ответ, потерявший связь с заявкой или документом, ещё не выполняет эту задачу.

WOPI и сетевой доступ проверяются по реальной схеме

В версии 10.0 для WOPI требуется явно указать хост в правилах ipfilter: одного allow: * недостаточно. Перед изменением найдите действительных участников обмена и применимую документацию. Не заменяйте разбор разрешением всем адресам или отключением проверки.

Новый порт 8083 по умолчанию относится к установкам DEB и RPM. Если используется контейнер, прокси или изменённая конфигурация, внешний адрес и внутренний порт выясняют отдельно. Переписывать каждый адрес на 8083 по заголовку обзора не следует: это может описывать другую поставку.

Учебный маршрут: просмотр прошёл, выгрузка не принята

Представим вымышленную систему согласования коммерческих предложений. Сотрудник открыл документ, изменил текст и запросил итоговую выгрузку. Команда проверила только открытие редактора, а серверную операцию оставила со старым способом авторизации. В таком сценарии общий статус «редактор работает» скрывает незавершённый путь пользователя.

Для приёмки выберите безопасный тестовый документ с отличимым содержанием. Заранее запишите ожидаемый формат, место результата и разрешённого получателя. Затем проверьте весь маршрут, включая отказ в непредусмотренной операции. Это не инструкция обхода авторизации, а способ убедиться, что разрешения соответствуют назначению процесса.

Редакция и способ установки входят в условия задачи

Обзор производителя отдельно относит административные возможности к коммерческим редакциям. Нельзя переносить весь набор Enterprise или Developer на Community по одному номеру версии. В задании на обновление укажите редакцию и установку, прежде чем обещать конкретный интерфейс администратора.

Точно так же отсутствие функции в выбранной редакции не надо маскировать технической ошибкой. Отметьте ограничение и согласуйте нужный способ выполнения задачи. Это помогает отделить исправление интеграции от изменения состава продукта или условий использования.

Что должно остаться после приёмки

1. Запишите редакцию, способ установки и реальные участки обмена.
2. Перечислите все используемые endpoint и назначение их полномочий.
3. Сверьте обязательность operation для каждого типа запроса.
4. Подтвердите WOPI-хосты и сетевой путь, если они используются.
5. Пройдите разрешённый маршрут документа и отказ для неподходящей операции.
6. Проверьте возврат результата в нужную задачу бизнес-системы.
7. Сохраните состав проверенной поставки и оставшиеся ограничения.

Для разработки веб-приложения с документами такой маршрут задаёт предмет приёмки. В интеграции API разделяйте полномочия разных операций, а при поддержке сервера фиксируйте фактическую схему установки и прокси. Это полезнее общего обещания, что любая старая интеграция совместима с новой версией.