pgAdmin

Декодує версію з рядка запиту ?ver=NNNNN для скидання кешу, який pgAdmin додає до кожного статичного ресурсу на власній сторінці входу, — анонімно за задумом, оскільки сторінка має відобразитися ще до появи будь-якої сесії.

targets:
  - id: pgadmin-main
    product: pgadmin
    address: https://pgadmin.example.com

Автентифікація

Немає — ендпоінт не приймає жодного виду облікових даних.

Як декодується версія

Підтверджено на реальному контейнері dpage/pgadmin4 і у власному коді pgAdmin (version.py): NNNNN — це APP_VERSION_INT, задокументований там як [X]XYYZZ — реліз, ревізія, потім код суфікса — наприклад, 91700 для релізу 9, ревізії 17, суфікса 00 (GA). У version відновлюється лише основа release.revision; ненульовий код суфікса (beta/dev-збірка) не має задокументованого текстового відповідника, за яким його можна було б відновити з самого коду, тому він виводиться як extra.suffixCode, а не вгадується.

Записувані поля

• version — наприклад, 9.17
• extra.suffixCode, лише якщо ненульовий

Зіставлення з CVE

Зіставляється з NVD і БДУ ФСТЕК, якщо налаштовано блок cve:.

Резолвер життєвого циклу

github-tags:pgadmin-org/pgadmin4. endoflife.date не має календаря pgAdmin (підтверджено 404), а pgadmin-org/pgadmin4 взагалі не має GitHub Releases (підтверджено наживо: ендпоінт релізів повертає порожній масив) — лише теги у формі REL-9_17, а не версію з крапками. Тип резолвера github-tags існує саме для цього: він перетворює цю форму на 9.17 і вибирає тег з найвищою розібраною версією з отриманої сторінки, а не покладається на порядок у списку, оскільки ендпоінт тегів не документує жодної гарантії порядку, на відміну від зворотного хронологічного порядку Releases. Як і звичайний резолвер github:, він знає лише «останню версію» — без дат eol/support/lts, оскільки ендпоінт тегів їх не містить. Про змінну середовища GITHUB_TOKEN, яка підвищує ліміт запитів цього резолвера, див. Підтримувані продукти.