fix(vulnogram-api): treat non-login 3xx as valid session in probe

[potiuk]

Summary

vulnogram-api-check was returning error: HTTP 302 whenever the probe URL redirected to a non-login destination. Upstream Vulnogram now 302-redirects /cve5/new → /allocatecve (the PMC-gated allocation page), and the probe code treated any non-OAuth 3xx as an unknown error.

This was producing false-negative "expired" diagnoses on adopter machines whose sessions were actually working — vulnogram-api-record-update (which hits a different endpoint) kept succeeding, so security-issue-sync was incorrectly falling back to the "manual paste required" release-manager hand-off variant on trackers whose CVE JSON had in fact been auto-pushed.

Fix

_is_login_redirect already encodes the only failure mode worth detecting (3xx to oauth.apache.org or /users/login → session expired). Any other 3xx means the app processed the session cookie successfully and chose to redirect to a different authenticated page — the session is valid; only the post-auth landing page changed.

The fix is a one-line additive condition in probe() plus a regression test covering the /cve5/new → /allocatecve case.

Diff

File	Δ
tools/vulnogram/oauth-api/src/vulnogram_api/client.py	+8 −1 (probe() accepts non-login 3xx as valid, with docstring explaining why)
tools/vulnogram/oauth-api/tests/test_client.py	+9 (new test_probe_valid_on_non_login_redirect)

Test plan

• pytest tests/test_client.py — 14 tests pass (was 13 + the new regression test).
• Live probe with my Apache OAuth session: previously returned error: HTTP 302, now returns valid (URL redirects to /allocatecve as expected).
• Live push via vulnogram-api-record-update for 3 CVEs (CVE-2026-27173, CVE-2026-42359, CVE-2026-42526) — all succeeded, demonstrating that the session is functional and the probe was the false negative.
• Other adopters with valid sessions confirm vulnogram-api-check flips from error: HTTP 302 → valid after this lands.

Why "treat as valid" instead of changing the probe URL

The alternatives considered:

• Change probe URL to /cve5 (dashboard) — would work for now but breaks again the next time Vulnogram reshuffles routing.
• Follow redirects in _request — invasive change to _request's contract; other call sites rely on seeing the raw 3xx.
• Accept non-login 3xx as valid (this PR) — minimal change, doesn't pin to a specific URL, and the semantic is correct: "we got past auth" is what we wanted to probe.

🤖 Generated with Claude Code

[potiuk]

Hah !! We have direct pushing of CVE to vulnogram working :)