Кратко

  • DAV:current-user-principal — защищённое вычисляемое для каждого запроса свойство; оно возвращает один HTTP(S)-URL ресурса принципала или псевдопринципал unauthenticated.
  • Выбранный URL запускает последующие запросы, но не перечисляет все представления личности, не заменяет глобальный идентификатор и не даёт право на операцию.
  • Наблюдаемая цепочка разделяет сервис, TLS, аутентификацию, выбор принципала, доступ к его ресурсу, домашнюю коллекцию, привилегию, метод и фактический результат.

Один зелёный этап закрыл остальные

RFC 3744 описал принципы WebDAV ACL: пользователей и группы как ресурсы принципалов, списки доступа и набор привилегий текущего пользователя на конкретном ресурсе. Однако клиенту не хватало прямого рекомендуемого ответа на вопрос, какой ресурс принципала сервер связывает с только что аутентифицированным HTTP-пользователем.

Отчёт DAV:principal-match мог вернуть индивидуальный принципал и все группы, куда он входит. Для анализа членства это корректно. Для настройки учётной записи результат неоднозначен: какой элемент должен стать отправной точкой?

RFC 5397 добавил DAV:current-user-principal. Значение — один DAV:href или DAV:unauthenticated. URL обязан использовать HTTP(S) и входить в набор URL, объявленных ресурсом принципала. Клиент получает авторитетно выбранную точку и затем запрашивает группы, альтернативные адреса или домашние коллекции приложения.

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

Представление не обязано быть единственным

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

Поэтому href нельзя без контекста делать глобальным ключом человека. Реорганизация каталога меняет путь, не обязательно меняя пользователя. Одинаковые пути у разных сервисов не доказывают одинаковую личность.

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

Необъяснимое изменение URL — повод для проверки версии, миграции, привязки сессии и identity mapping. Это не автоматическое доказательство атаки и не лицензия молча создать второго пользователя или склеить две истории.

Свойство вычисляется для запроса

Клиент не может установить текущее значение: оно защищено и вычисляется сервером для каждого запроса. COPY и MOVE его не переносят. Текущий пользователь описывает контекст обращения к ресурсу, а не сохранённое качество документа.

Если экспорт записывает значение в постоянные метаданные, он прикрепляет старого запрашивающего к будущим просмотрам. Журнал автора операции может быть нужен отдельно, но он не заменяет новое вычисление текущего принципала.

RFC 6764 разрешает кэшировать успешные параметры обнаружения, включая URL принципала. При устойчивом сбое соединения или аутентификации клиент должен повторить SRV-поиск и обнаружение учётной записи. У кэша есть происхождение и триггер обновления; он не становится источником власти.

Это разделяет старый endpoint, плохие credentials, новое отображение принципала, недоступный principal resource, отсутствующий home и изменившиеся права. Общий красный статус скрывает всех владельцев.

Unauthenticated нельзя заменять прошлой личностью

Если аутентификация не выполнена или провалилась, RFC 5397 требует DAV:unauthenticated. Это явный отрицательный результат, а не пустое место для последнего успешного URL.

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

RFC 6764 требует заставлять пользователя аутентифицироваться при PROPFIND, запрашивающем это свойство. Если свойство не пришло, клиенту может понадобиться спросить путь у пользователя. Отсутствие запускает запасной процесс настройки, а не разрешает выдумать ответ.

Отдельные метрики для отказа аутентификации, отсутствия свойства и ошибки ресурса принципала дают разным командам точную работу. Одно null-значение толкает к опасному восстановлению старого состояния.

Идентичность не вычисляет права на все цели

Текущий принципал указывает, где продолжать исследование личности. DAV:current-user-privilege-set из RFC 3744 сообщает рассчитанные сервером права этого пользователя на конкретном ресурсе.

Пользователь может читать свой principal resource и не писать в календарь. Членство в группе может участвовать в ACL и не давать доступ к каждой адресной книге. Даже право записи не отменяет условие ETag или конфликт версии.

В CalDAV и CardDAV последовательность длиннее одного свойства: найти сервис, проверить TLS, аутентифицироваться, получить принципал, обнаружить home, достичь коллекции, оценить права, выполнить метод и увидеть состояние.

Полезная панель показывает отдельные чеки. Principal найден может оставаться зелёным, а home — неизвестным, write — запрещённым, итог — неподтверждённым. Это точность, а не усложнение.

Достаточно структуры, а не полного каталога

Для разделения этапов не нужно копировать все ACL и группы в центральный лог. Достаточны ограниченные поля: сервис, correlation ID, класс аутентификации, форма ответа, scoped-идентификатор URL, состояние следующего ресурса, решение о привилегии и результат.

Личность и членство чувствительны. Нужны минимизация, контроль доступа и срок хранения. Раздельные квитанции снижают сбор: команде не приходится сохранять весь каталог, чтобы понять, на каком переходе возникла ошибка.