Кратко

  • RFC 9670 стандартизирует Principals, ShareNotifications и форму прав для разделяемых объектов, но не определяет, что именно можно делить и насколько мелкими должны быть права.
  • Надёжный отзыв подтверждает запрет новых операций в сервисе; экспорт, офлайн-кэш и иные копии вне его управления требуют отдельной политики и не исчезают от смены state.

Сотрудника убрали из shareWith. Получатель перечитал объект: его myRights больше не разрешали чтение. Новый запрос вернул отказ. Через минуту тот же человек открыл ноутбук без сети и прочитал вчерашнюю локальную копию.

Обе картины совместимы. Сервер отозвал живое полномочие. Файл уже покинул его поверхность контроля.

RFC 9670 полезна именно своей узостью. Она добавляет JMAP единый способ описывать сущности совместной работы, изменения прав и разделяемые данные. Principal может быть человеком, группой, помещением, устройством или другой сущностью. ShareNotification фиксирует изменение прав. Тип данных, который хочет поддерживать sharing, должен определить isSubscribed, myRights и shareWith.

Но спецификация не выбирает объекты и не задаёт гранулярность permission. Их смысл определяет конкретный тип данных. Она также не обещает управление офлайн-копиями.

Карта назначения и фактическое право не совпадают автоматически

shareWith связывает Principal IDs с картами прав. myRights показывает текущие права пользователя, который читает объект. Формат похож, однако наблюдатель и вопрос различны.

Владельческая сторона видит назначение. Получатель видит вычисленный результат для себя. Политика сервера, тип данных, групповая принадлежность и состояние объекта могут влиять на итог. После изменения нужно сохранить обе стороны и выполнить конкретную операцию — чтение, изменение, удаление или администрирование. Успех одной не доказывает другую.

Owner Account не включается в shareWith, потому что его права неявны. Поэтому сама карта никогда не является полным списком субъектов власти.

isSubscribed отвечает на третий вопрос: хочет ли пользователь видеть ресурс в обычной рабочей области. Разрешение может существовать без подписки. Сервер вправе отклонить подписку, не отзывая permission. Отсутствие объекта в списке нельзя автоматически считать запретом.

Principal нужно связать с управляемой идентичностью

RFC 9670 предоставляет Principal ID и свойства представления, но управление набором Principals оставляет directory или другому доменному сервису. Рабочая квитанция должна сохранять ID, поколение каталога, вид Principal, Account идентичности, Object Account и его owner.

Имя и email помогают выбрать адресата, но не являются строгим доказательством. RFC предупреждает: редактируемые поля позволяют имитировать другого человека. Запрет точных дублей не защищает от похожего написания и визуально сходных Unicode-символов.

Открытая регистрация Principals тоже опасна. Спецификация требует строго контролировать их множество, иначе растут случайные раскрытия, нежелательные объекты и notification spam.

Следовательно, первая проверка sharing происходит до API: организация должна доказать, кто контролирует выбранный Principal сегодня и не был ли ID переиспользован.

Состояние защищает от устаревшей записи

Два администратора могут одновременно редактировать целую карту shareWith. Без предиката последний save перезапишет результат первого.

RFC 8620 определяет ifInState. Клиент прикладывает state, на котором построил изменение. Если сервер уже продвинулся, /set завершается stateMismatch. Ответ отдельно сообщает updated и notUpdated, oldState и newState.

Нужно хранить прежний state, хэш карты, условие, результат каждого объекта и новый state. Это защищает порядок решений. Но state string остаётся механизмом синхронизации, а не журналом акторов, причин, доставки уведомлений или пользовательского результата.

Даже идеальная conditional write говорит только: данная мутация применилась к ожидаемой версии. Она не доказывает правильность Principal, эффективное enforcement или отсутствие сохранённых копий.

ShareNotification может быть неполной по правилам

ShareNotification создаётся сервером и содержит объект, его Account, старые и новые myRights, время, имя и changedBy. principalId инициатора может отсутствовать.

Сервер должен обычно создать уведомление, но может не выпускать отдельные записи для групповых изменений, если поток станет чрезмерным. Он может объединять, ограничивать и удалять старые уведомления. При заполнении новое событие способно вытеснить самое старое. RFC отмечает, что это может скрыть важное изменение.

Поэтому notification ID — квитанция серверной записи в рамках политики. Она не доказывает, что клиент получил и показал её, а человек прочитал. Отсутствие записи также не всегда доказывает отсутствие изменения.

Точная формула отзыва

Правильная процедура удаляет Principal с условием state, читает обновлённые shareWith и myRights, затем проверяет новую операцию от имени получателя. Формулировка результата: «с поколения X и времени T сервис отклоняет такие операции этого Principal».

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

Security Considerations показывают, почему границы важны. Краткий доступ к разблокированному клиенту может стать постоянным через новый share. Подмена Principal вводит владельца в заблуждение. Массовые изменения создают denial of service для notification-хранилища. Каждая угроза использует разрыв между корректным протокольным объектом и неверным организационным выводом.

Минимальная общая спецификация координирует representation. Доверие появляется только после связанной цепочки identity, state, readback, operation и copy boundary.

Источники