Настройка сервиса
Эта страница относится к текущей реализации 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
Секции пакетных менеджеров
Каждая экосистема содержит флаг enabled и список repository. Имя репозитория становится частью URL OSA Proxy:
Такой репозиторий будет доступен по адресу:
Поля scan-manifest и scan-package включают проверку манифестов и скачиваемых артефактов. Поддержка этих режимов зависит от экосистемы; подробнее см. Поддерживаемые протоколы. Параметр work-mode на уровне репозитория переопределяет глобальный codescoring.work-mode.
Особенности экосистем
Для composer и pypi доступны packages-registry и additional-packages-registries, если артефакты загружаются с отдельных хостов. Для go указывается sumdb-registry, если нужно проксировать SumDB. Для Docker используется auth-token-url.
Кэш вердиктов
По умолчанию Redis-кэш выключен:
Чтобы включить кэширование:
Логирование
Уровень логирования задается в logging.level. Поддерживаются значения debug, info, warn и error.
Справочник параметров
Корневые секции
Общие параметры секций пакетных менеджеров
Специфичные параметры репозиториев
file-type-filter
Фильтр работает только для репозиториев не-Docker экосистем. Если секция file-type-filter отсутствует или задана как {}, фильтр выключен: OSA Proxy работает как без фильтра, то есть запросы проходят по обычным правилам handler'а и совместимость с прежним поведением сохраняется. Чтобы включить фильтр, добавьте хотя бы одно из полей additional-allowed-extensions / scanned-extensions. Учитывается именно наличие ключа: например, additional-allowed-extensions: [] включает фильтр, но не добавляет расширений сверх встроенного preset.
При включенном фильтре OSA Proxy:
- пропускает metadata/manifest-запросы без проверки расширения;
- извлекает имя файла из URL path, декодирует URL-encoded символы и сравнивает расширение без учета регистра;
- разрешает файл, если его расширение входит во встроенный preset экосистемы или в
additional-allowed-extensions; - разрешает sidecar-файлы checksums и подписи (
.metadata,.sha256,.sha512,.sha1,.asc,.md5), только если базовый артефакт тоже разрешен; - сразу блокирует все остальные package file-запросы до обращения к upstream и CodeScoring.
Встроенные presets:
Для Debian также разрешаются source tarballs вида .orig-*.tar.gz, .orig-*.tar.xz и .orig-*.tar.bz2.
additional-allowed-extensions расширяет только allow-list фильтра. Само наличие этого поля переводит репозиторий в режим allow-list: OSA Proxy разрешает встроенные расширения экосистемы и расширения из additional-allowed-extensions, а все остальные неизвестные package file-расширения блокирует. Параметр нужен, когда в репозитории есть допустимые файлы с нестандартными расширениями и их не нужно блокировать самим фильтром. Он не заставляет handler отправлять такие файлы на package scan: если стандартная стратегия экосистемы не считает расширение сканируемым, запрос пройдет дальше как обычный passthrough. Чтобы новый тип файла также участвовал в 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 в зависимости от маршрута.
Пустая секция также оставляет фильтр выключенным:
Чтобы включить фильтр без добавления новых расширений, можно задать пустой список. Тогда для 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 будет заблокирован фильтром.
