Synology DSM

Входить у власний Web API Synology (SYNO.API.Auth), а потім читає версію з SYNO.DSM.Info, використовуючи отриманий сеанс, — це єдина HTTP-проба в enodia, якій потрібен справжній крок входу, а не статичні облікові дані.

targets:
  - id: nas-main
    product: synology-dsm
    address: https://nas.example.com:5001
    credentials: synology-admin

Автентифікація — обовʼязкова, імʼя користувача та пароль

credentials:
  synology-admin:
    kind: password
    username: enodia-ro
    password: "${SYNOLOGY_PASSWORD}"

Підтверджено наживо: SYNO.DSM.Info завжди відповідає {"error":{"code":119}} («немає сеансу») без ідентифікатора сеансу і, якщо ввімкнено захист від CSRF, без SynoToken — жодне з них неможливо отримати, не викликавши спочатку метод входу SYNO.API.Auth зі справжнім обліковим записом і паролем. Це справді легший випадок, ніж повноцінний вхід через HTML-форму: звичайний JSON API, що приймає імʼя користувача й пароль як звичайні параметри та повертає ідентифікатор сеансу як звичайне поле JSON, без сховища cookie чи вилучення CSRF-токена. Після читання версії виконується вихід (за можливості), щоб збирання даних не накопичувало відкриті сеанси на NAS від запуску до запуску.

Помилки автентифікації тут взагалі не використовують коди стану HTTP: кожен виклик Synology Web API відповідає 200 навіть у разі невдачі, з success: false у тілі — підтверджено наживо, тому ця проба читає тіло, а не код стану, щоб виявити відхилений вхід.

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

Лише version — видобувається з рядка version_string вигляду "DSM <version> Update <n>", напр. "DSM 7.3.2-86009 Update 4" → 7.3.2-86009.

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

Не зіставляється — його діапазони використовують межі на кшталт 6.2.4-25556-3, які строгий парсер діапазонів відхиляє. Див. Зіставлення з CVE.

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

Немає — endoflife.date не має календаря під synology-dsm, synology чи dsm (підтверджено 404). Поки що лише для інвентаризації.