Description
Release review finding P1.2 remains live at src/meraki_dashboard_exporter/api/client.py:42-51. Redirect authentication is currently preserved only for the configured origin, so legitimate Meraki shard or regional hosts can lose Authorization and enter a persistent 401 path. The redirect boundary must preserve credentials only for documented Meraki-owned host suffixes while stripping them for attacker-controlled lookalikes.
Acceptance Criteria
- #1 A legitimate Meraki shard or regional redirect retains the Authorization header
- #2 A lookalike host such as a Meraki name under an attacker-controlled parent domain loses the Authorization header
- #3 Tests cover legitimate shard, attacker-controlled lookalike, and existing same-origin behavior
Definition of Done
- #1 just check (ruff format –check, ruff check, mypy, generated-doc drift, offline API conformance, and the marker-filtered pytest run with the 80% coverage floor — this is exactly what the CI
testjob runs) - #2 just gen, when metrics, config, endpoints, collectors, the settings schema or the chart config changed —
just checkincludes the drift gate and CI fails the build on it - #3 Grafana queries in grafana/dashboards/*.json and grafana/alerts/ updated, if a metric or label name changed
Implementation Plan
Implement the host-boundary redirect credential policy in the existing API client with failing tests for legitimate Meraki shards and attacker-controlled lookalikes, then run the focused API tests.
Implementation Notes
Test-first redirect coverage now preserves Authorization only between configured or Meraki-owned HTTPS origins and strips it for attacker-controlled lookalikes. Integrated gate: 2827 passed.
Final Summary
Implemented a suffix-boundary Meraki redirect trust policy with regional/shard, lookalike, and same-origin tests; just check and just ci pass.