Кратко

  • Open Cloud Mesh сообщает получателю о предоставленном доступе, но заканчивает работу до операции WebDAV, SSH или приложения, которая должна реализовать это право.
  • Новый проект интеграции OCM показывает важную границу: уведомление, действительная учётная информация и успешная операция — разные записи.

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

draft-ietf-ocm-integration-protocol-00, первая версия рабочей группы от 11 сентября, делает это различие явным. OCM координирует федерацию: Sending Server сообщает Receiving Server, что сторона получила доступ к Resource. Сам доступ происходит позже по WebDAV, SSH или протоколу приложения. Проект позволяет поручить эту работу Protocol Server, не меняя видимую для принимающего узла модель.

Это границы реальности: объявление, авторизация, исполнение и итог нельзя считать одним событием.

Уведомление указывает следующий шаг

Share Creation Notification несёт стороны, providerId, параметры протокола, разрешения и срок. Оно может указать адрес следующего запроса, но не содержит его результата.

providerId связывает состояние Share в обратном канале с доступом во фронтальном. Однако проект называет его идентификатором, а не credential; знание значения не должно давать доступ. Авторизация выводится из проверенного access token или, в introspected-режиме, из подтверждения активного состояния учётных данных.

Даже валидный JWT доказывает ограниченное утверждение. Подпись подтверждает издателя и целостность claims. Protocol Server всё равно проверяет issuer, audience, subject, срок, pairing и состояние Share, затем применяет разрешения. Хранилище или приложение после этого исполняет операцию. Верная подпись не создаёт отсутствующий файл, не выбирает нужную версию и не превращает ошибку WebDAV в завершённую передачу.

Один ложный успех прямо запрещён

В provisioned-режиме OCM Server сначала отправляет подписанный Share Provisioning Request. Protocol Server проверяет его, сохраняет Share Record и подтверждает успех. Лишь затем разрешено послать Share Creation Notification.

Если provisioning не удался, Share создавать нельзя: иначе получатель узнает о доступе, который не способен работать. Правило устраняет состояние «объявлено, хотя сервер доступа отказал».

Будущие попытки оно не гарантирует. Обмен токеном может сорваться, токен истечь, привязка личности не совпасть, Resource переместиться, Protocol Server стать недоступным, а нижележащий протокол вернуть ошибку. Точная квитанция гласит «provisioning успешно завершён до уведомления», но не «получатель использовал ресурс».

Три режима и три времени отзыва

Provisioned, self-contained и introspected могут выглядеть одинаково для получателя, однако хранят разные состояния.

Provisioned держит Share Record и поддерживает явный отзыв. Self-contained помещает сведения Share в подписанный claim ocm_ip; выпущенный токен действует до истечения срока. Introspected проверяет активность, но кэшированный положительный ответ задерживает отзыв.

Поэтому запись «отозвано в 14:00» не определяет фактический конец доступа. В зависимости от режима важны удаление Share Record, срок последнего токена или горизонт кэша introspection. Внутреннюю топологию не нужно раскрывать узлам, но оператор обязан локально сохранить режим и действительно завершённое действие жизненного цикла.

Последнее доказательство даёт протокол доступа

Ошибки фронтального канала сохраняют смысл WebDAV, SSH или приложения. OCM не должен утверждать результат, которого не наблюдает.

Для WebDAV подтверждение может включать метод, HTTP status, ETag или версию и завершение body. В SSH аутентификация и открытие сессии не доказывают исполнение команды или копирование файла. В веб-приложении открытая разрешённая страница не подтверждает окончание вычислительной задачи.

Минимальная цепочка соединяет пять слоёв: уведомление Share; выдачу или introspection credential; решение Protocol Server; ответ протокола и версию Resource; итог в приложении получателя. Панель может свести их, но не вправе стереть происхождение фактов.

Источники