Skip to content

v0.1.2 — device-passwords write surface

Latest

Choose a tag to compare

@Fill84 Fill84 released this 27 Apr 00:04
· 5 commits to main since this release

Patch release adding the Device Passwords card to the Security tab. The backend operation already existed as a write-safety-gated library call; this release exposes it through the same UI safety net as the other lockout-risky writes.

Changes

  • DevicePasswordsCard. Mirrors the legacy applet's two-fieldset layout (Read-Only / Operator and Read-Write / Manager) with username + password + confirm fields. Live confirm-mismatch validation; Manager fields are required, the Operator pair is optional (leave empty to keep current). Card sits first in the Security tab stack to match the applet ordering.
  • Two prominent warning banners. Physical-recovery lockout: a wrong Manager password is recoverable only via the chassis reset button — there is no software path back. Cleartext-on-the-wire: the 2810 firmware sends the new password as a query-string parameter on a plain HTTP GET (a protocol-level flaw mirrored faithfully). Pick the right link before applying.
  • New PUT /api/v1/security/device-passwords endpoint. Gated identically to the existing lockout-risky writes (web-access, web-managers): confirm_switch_host must match the configured switch host, a pre-write autobackup runs first, and READ_ONLY=true still blocks the call. The procurve_client.set_device_passwords operation existed before; this release simply exposes it through the same safety mechanism.
  • Tests. Negative test (endpoint-must-not-exist returns 404) replaced with five positive tests covering the read-only block, host-mismatch block, autobackup ordering, happy path, and a sanity check that the cleartext password does not echo back in the response body.

No other tabs touched. No backend protocol changes; no migrations.

Upgrade

git pull
docker compose up -d --build