Введение
Интеграция отгрузок читает ожидающие заказы и публикует обновления отправки. Текущий пример репозитория выглядит чистым, но удалённый API-ключ может ещё давать доступ. Вам нужно сдержать утечку и восстановить ожидающий запуск отправки.
Примените изученные методы: исследование Git, точечный отзыв, выбор областей, закрытую конфигурацию и бизнес-проверку. Завершите результат отправки, сохранив независимый монитор. Задание начинается в собственной подготовленной среде.
Восстановить интеграцию отгрузок
Текущая ситуация
Команда отправки использует подготовленный worker, читающий ожидающие заказы и публикующий обновления отправки. Например, после обработки пакета заказ O-201 должен получить состояние ready. Ключ удалили из текущего примера, но оповещение указывает, что его можно получить из истории. Пакет dispatch ожидает обработки. Независимый монитор доступности должен работать; временная пауза отправки допустима при сдерживании.
Используются тот же локальный учебный провайдер, методы Git, менеджер, формат INI и две роли терминала, что в лабораторных работах. Среда синтетическая и не требует внешнего аккаунта.
Используйте ключи этой VM, не предыдущей работы. Как в лабораториях с инструкциями, этот провайдер использует 401 для неверного или отозванного ключа, 403 для действительного ключа без нужной области, 200 для принятого чтения. Worker читает закрытый файл при каждом запуске; перезапуск сервиса не нужен.
Область работы
- Workstation открывается в
/home/labex/project/repository. Три коммита иshipping-example.iniсодержат исторические свидетельства. Текущий пример не является конфигурацией выполнения. - Integration работает под
keyworkerв/home/labex/project. Закрытый файл —runtime/job.ini; неизменяемый worker —/opt/keylab/worker.py, принимающий имя пакета аргументом. - API расположен на
http://127.0.0.1:8000. Key Manager использует токен оператора из/home/labex/.config/keylab/operator-tokenдля управления ключами. - Независимый монитор использует
lab_key_monitor_onlyдляGET /v1/health.
| Операция | Требуемая область | Бизнес-назначение |
|---|---|---|
GET /v1/orders |
orders:read |
Чтение ожидающих заказов |
POST /v1/shipment-updates |
shipment-updates:write |
Публикация состояний отправки |
GET /v1/results |
orders:read |
Просмотр принятых пакетов |
GET /v1/customers |
customers:read |
Независимый каталог клиентов |
GET /v1/health |
health:read |
Отдельный монитор |
Ваша цель
Исторически раскрытый ключ больше не даёт API-доступа. Неизменённый worker использует отдельную новую замену в закрытой конфигурации; принимающий сервис содержит полный результат dispatch под этой заменой. Доступ к каталогу клиентов для замены запрещён, независимый монитор исправен.
Критерии приёмки
- Исторический ключ отозван и получает
401при доступе к заказам, пока API остаётся доступным. - Настроенная замена активна, отличается от старого ключа и имеет ровно две бизнес-области отгрузки.
/home/labex/project/runtime/job.iniпринадлежитkeyworker, имеет режим600и читается этой служебной записью. Новый секрет отсутствует в файлах и коммитах репозитория.- Неизменённый worker прочитал назначенный
dispatchнастроенной заменой; API принял заказыO-201иO-202, оба в состоянииready, под тем же ID замены. - Замена получает
403для каталога клиентов. Неизменённый ключ монитора получает200от конечной точки здоровья.
Подсказки
Где может остаться удалённый секрет?
Сравните текущий пример с прежними коммитами. Сопоставьте исторический ID с записью менеджера; одного отображаемого имени недостаточно.
Почему действительная замена продолжает ошибаться?
Worker выполняет входной и выходной запросы. Таблица помогает отличить недостаточную область от неверного или отозванного секрета. Переменная оболочки не обновляет закрытый файл выполнения.
Что доказывает восстановление?
Демонстрации или сообщения терминала недостаточно. Посмотрите назначенный пакет в принимающем API и сравните ID ключа с настроенной заменой. Не изменяйте подготовленный worker.
Резюме
Вы перенесли реагирование на инцидент с задания поддержки на интеграцию отгрузок. Полный ответ делает исторический секрет недействительным, восстанавливает реальную операцию под отдельным ограниченным ключом, держит секреты вне контроля версий и сохраняет независимый доступ к сервису.
