Настройка сервиса
Эта страница относится к текущей реализации OSA Proxy. Архивная Java/Spring-реализация доступна в разделе Архивная Java/Spring-реализация.
Конфигурация OSA Proxy задается в файле osa-proxy.yml. Пример ниже показывает типовую рабочую конфигурацию с несколькими экосистемами, настройками CodeScoring, HTTP-клиента, Redis-кэша и логирования.
Для CodeScoring версии ниже 2026.20.0 укажите codescoring.legacy-judge: true. В версиях до 2026.20.0 используется legacy API Judge, а OSA Proxy по умолчанию работает с текущим API Judge.
Пример конфигурации
Секция codescoring
HTTP/1.1 status line поддерживает только ASCII. Текст с кириллицей, например Загрузка компонента заблокирована политикой безопасности, не передается в status line. Если причина блокировки должна отображаться в status line Nexus или пакетного менеджера, используйте в block-message только ASCII-символы, например Component download blocked by security policy.
Формирование URL из forwarded headers
Параметр osa-proxy-url-from-forwarded-headers нужен, когда один инстанс OSA Proxy доступен по нескольким внешним URL, например из двух сетевых контуров:
Reverse proxy каждого контура передает свой X-Forwarded-Proto и X-Forwarded-Host. OSA Proxy использует их при формировании абсолютных ссылок на пакеты в metadata и манифестах, поэтому клиенты каждого контура получают ссылки через доступный им URL. Например, ответы на запросы через osa-proxy.internal.example.com содержат ссылки с этим host, а запросы через osa-proxy.dmz.example.com — ссылки с host DMZ.
Если заголовок X-Forwarded-Proto отсутствует, используется https; если отсутствует X-Forwarded-Host, используется обычный Host. Включайте этот режим только за доверенным reverse proxy, который перезаписывает forwarded headers, а не пропускает значения от клиента.
Секции пакетных менеджеров
Каждая экосистема содержит флаг enabled и список repository. Имя репозитория становится частью URL OSA Proxy:
Такой репозиторий будет доступен по адресу:
Поля scan-manifest и scan-package включают проверку манифестов и скачиваемых артефактов. При scan-manifest: false metadata npm, NuGet и PyPI не проверяется, но ссылки в ответах по-прежнему переписываются на OSA Proxy. Поддержка режимов зависит от экосистемы; подробнее см. Поддерживаемые протоколы. Параметр work-mode на уровне репозитория переопределяет глобальный codescoring.work-mode.
Особенности экосистем
Для composer и pypi доступны packages-registry и additional-packages-registries, если артефакты загружаются с отдельных хостов. Для go указывается sumdb-registry, если нужно проксировать SumDB. Для ivy при scan-package: true необходимо явно выбрать layout: встроенный шаблон (sbt-default или ivy-default) либо пользовательский шаблон из корневой секции layouts. Для docker настраиваются auth-token-url, scan-container и codescoring-pull-through-proxy.
Интеграция с менеджерами репозиториев
Для поддерживаемых экосистем доступны дополнительные варианты передачи в OSA Proxy контекста репозитория и пользователя JFrog Artifactory. Подходящий вариант зависит от версии и конфигурации Artifactory. Подробности по запросу предоставляет поддержка вендора.
Секции artifactory и nexus позволяют периодически получать inventory менеджера репозиториев и автоматически создавать маршруты для выбранных экосистем. Полная настройка discovery, credentials, URL, repository context и ответов о блокировке сгруппирована в отдельных разделах:
Кэш вердиктов
По умолчанию Redis-кэш выключен:
Чтобы включить кэширование:
Логирование
Уровень логирования задается в logging.level. Поддерживаются значения debug, info, warn и error.
Справочник параметров
Корневые секции
Общие параметры секций пакетных менеджеров
Специфичные параметры репозиториев
file-type-filter
Фильтр работает только для репозиториев не-Docker экосистем. Он выключен, пока
явно не задано enabled: true, в том числе при секции {} или заполненных
списках расширений. В выключенном состоянии запросы обрабатываются по обычным
правилам handler'а.
При включенном фильтре OSA Proxy:
- пропускает metadata/manifest-запросы без проверки расширения;
- извлекает имя файла из URL path, декодирует URL-encoded символы и сравнивает расширение без учета регистра;
- разрешает файл, если его расширение входит во встроенный preset экосистемы или в
additional-allowed-extensions; - всегда разрешает checksum-суффиксы
.sha256,.sha384,.sha512,.sha-256,.sha-384,.sha-512,.sha1и.md5; - разрешает sidecar-файлы
.metadataи.asc, только если базовый артефакт тоже разрешён; - сразу блокирует все остальные package file-запросы до обращения к upstream и CodeScoring.
Встроенные presets:
Для Debian также разрешаются source tarballs вида .orig-*.tar.gz, .orig-*.tar.xz и .orig-*.tar.bz2.
additional-allowed-extensions только расширяет allow-list: это поле не
включает фильтр и не заставляет handler отправлять такие файлы на package scan.
Чтобы новый тип файла участвовал в package scan, добавьте расширение также в
scanned-extensions.
scanned-extensions используется для второго поведения: файлы с этими расширениями считаются сканируемыми package artifacts, даже если стандартная стратегия экосистемы их не распознает. Для таких расширений включается кэш результата сканирования на короткое время, чтобы родственные файлы с одной базой имени могли использовать один вердикт. Например, для Maven можно указать scanned-extensions: [.jar, .pom], чтобы demo-1.0.0.jar и demo-1.0.0.pom группировались по базе demo-1.0.0.
Пример:
В этом примере .tgz разрешается preset'ом npm и участвует в package scan, а .license дополнительно разрешается фильтром, но не становится сканируемым артефактом.
Пример поведения для npm
Без секции file-type-filter фильтр выключен. Npm handler работает по стандартной логике: package tarball left-pad-1.0.0.tgz отправляется на package scan, а остальные запросы обрабатываются как metadata или passthrough в зависимости от маршрута.
Пустая секция также оставляет фильтр выключенным:
Чтобы включить фильтр без добавления новых расширений, задайте enabled: true.
Тогда для npm разрешены только встроенный preset .tgz и применимые
sidecar-файлы. Запрос к left-pad-1.0.0.tgz пройдёт и будет проверен, а запрос
к left-pad-1.0.0.exe будет заблокирован до upstream и CodeScoring.
Если нужно разрешить нестандартный файл, но не отправлять его на package scan, добавьте расширение только в additional-allowed-extensions:
В такой конфигурации .tgz будет сканироваться как npm package, .license пройдет фильтр как допустимый файл, а .exe будет заблокирован фильтром.
codescoring
codescoring.resilience.retry
codescoring.resilience.circuit-breaker
http.server
http.client
cache.judge
cache.redis
Полная настройка TLS, корпоративных CA, Docker Compose и Helm приведена в разделе Настройка Redis и кэширования.
logging
OSA Proxy пишет логи в JSON. Для каждого входящего запроса создаётся одно
завершающее событие уровня info с именем http request completed и полями
component, method, ограниченным по cardinality route, путём запроса
path без query-параметров, status, status_class, outcome и
duration_ms. При наличии tracing context событие также содержит trace_id и
span_id.
admin
Подробнее см. в разделе Admin API и управление.
configuration-store
Подробнее см. в разделе Admin API и управление.
layouts
Корневая секция layouts содержит карту пользовательских шаблонов путей для репозиториев Ivy (sbt). Ключ — имя шаблона, значение — строка формата раскладки каталогов:
Подробнее см. в разделе Настройка Ivy.
webhooks
Секция webhooks задает список подписок на исходящие HTTP POST-уведомления:
Подробнее см. в разделе Настройка webhooks.
