Кратко

  • Индивидуальный проект от 28 октября предлагает два взаимоисключающих поля OAuth: client_ip_ranges содержит префиксы IPv4 и IPv6, client_ip_ranges_uri указывает на JSON-документ по HTTPS. Регистрация метаданных и успешное получение файла ещё не означают принятие его диапазонов сервером.
  • Ошибка загрузки, неверный файл или отзыв объявления сами по себе не расширяют допуск. Сервер может сохранить прежний принятый набор, сократить его до пересечения с ожидающим одобрения новым набором и установить срок хранения. После истечения срока сервер, применявший ограничение, отклоняет запросы до принятия актуального набора или явного решения снять контроль.

Объявить адрес проще, чем получить разрешение

Компания переносит OAuth-клиент на другой облачный выход. Новый файл доступен и отвечает HTTP 200. Однако точка выдачи токенов всё ещё принимает старые источники. Проект сохраняет этот разрыв намеренно: получение документа и принятие его содержимого — разные действия. Сервер проверяет весь набор, затем решает по своей политике, можно ли расширить доступ. Слишком широкий префикс не становится пропуском только потому, что появился в файле.

У клиента два способа объявления: перечислить префиксы прямо в метаданных либо указать HTTPS-адрес документа. Совместить их нельзя. Нет обоих полей — нет объявления; пустой массив объявляет пустой набор. При обновлении по RFC 7592 проект требует считать пустой массив именно объявлением, а не просьбой удалить поле. Если сервер принял и применяет пустой набор, ни один исходный адрес не проходит.

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

Поломка файла не открывает турникет. Неудачное получение или проверка не должны допускать ранее запрещённый источник. Отзыв объявления также не ослабляет ограничение автоматически: нужно явное локальное решение. Серверу следует ограничить срок использования старого набора при сбое, отзыве или ожидании новой версии. Когда срок истёк, применявший фильтр сервер отклоняет запросы, пока не примет набор по текущему объявлению или явно не отменит применение. Повторная проверка ещё не одобренной замены не запускает часы заново.

Бесконечно хранить старый список тоже опасно. Отказавшийся от адреса клиент может потерять над ним контроль, а адрес получит другой пользователь. Пересечение и срок хранения сокращают эту щель. RFC 9111 описывает HTTP-кэш, но принятый сервером набор — отдельное состояние. 304 Not Modified подтверждает сохранённый ответ, не решение о доступе; истёкший кэш сам по себе не отнимает старое разрешение.

Межсетевой экран перед точкой выдачи токенов видит IP, но не обязательно знает OAuth-клиента. Он способен применять только объединение диапазонов клиентов. Сам сервер после идентификации проверяет индивидуальный набор. Совпадение IP не удостоверяет клиента. Если подписанное заявление содержит только URL документа, подпись подтверждает URL, а не все будущие версии файла у его владельца. Владелец может лишить клиента доступа, опубликовав пустой набор или надолго убрав файл.

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

Источники: проект; статус IETF; RFC 7592; RFC 9111.