Кратко

  • RFC 9865 определяет непрозрачный курсор для получения следующей страницы той же SCIM-выборки через тот же endpoint и с теми же параметрами.
  • Владение курсором не добавляет привилегий: при переходе по набору сервис обязан постоянно применять авторизацию текущей личности действующего лица.

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

RFC 9865 задаёт строгую форму этой последовательности. Первый запрос использует пустой или отсутствующий cursor. В следующем запросе клиент обязан оставить тот же endpoint поставщика и все параметры и значения исходного запроса, меняя лишь cursor на значение, вернувшееся ранее. Значение непрозрачно для клиента. Во всех ответах, кроме последней страницы, должен быть nextCursor; previousCursor необязателен и недопустим на первой странице. Норма делает проверяемым продолжение одного вопроса. Она не делает набор данных постоянным и не продлевает разрешение, когда-то выданное для первой страницы.

Поля количества также нельзя превратить в более сильное свидетельство. count задаёт желаемый максимум: поставщик не может вернуть больше, но может вернуть меньше. При count=0 ресурсы не возвращаются, остаётся только totalResults; и этот итог может отсутствовать, если его нельзя оценить. Число в ответе не доказывает полноту каталога и не говорит, что та же совокупность будет доступна позже. Поставщик вправе сделать курсор единственным методом пагинации. При поддержке индекса и курсора он выбирает метод по умолчанию и может опубликовать возможности через Service Provider Configuration.

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

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

У состояния есть и цена доступности. Если сервер держит большие данные для каждого курсора, множество первоначальных запросов способно истощить его ресурсы. RFC рекомендует аутентификацию для крупных выборок, ограничение частоты, административный потолок на число курсоров или размер страницы и экономную инвалидизацию. Неопубликованный timeout или maximum page size не означает, что локальных пределов нет. Отсутствие поля в конфигурации не заменяет проверку работающей политики.

Подход Heng Lu сохраняет верный масштаб утверждения. Спецификация даёт общий, детерминированный способ договориться о следующем шаге запроса. Текущая авторизация, реализация, эксплуатация и решение, принятое на основе возвращённых данных, остаются отдельными локальными действиями. Курсор продолжает список. Право доступа сервис обязан установить заново.

Sources