[aterga]

Summary

The status dashboard's OAuth Dynamic Client Registration check went red once the hosted-redirect allow-list shipped (#69) and reached beta. It registered with a hosted redirect (https://example.org/callback) and expected a client_id; the allow-list now correctly rejects that with 400 invalid_redirect_uri. The failure is expected server behavior — the check was stale.

This fixes the check to reflect the new reality, and adds a check that positively monitors the guard.

Related issues

Follows #69 (hosted-redirect allow-list, CWE-601). No GitHub issue open.

Changes

• oauth-register: register a loopback redirect (http://127.0.0.1:8765/callback) instead of a hosted one. Loopback is always permitted (the allow-list exempts it), so this still confirms a client can self-register and receive a client_id — the case DCR exists for — without coupling the check to any vendor domain.
• oauth-register-allowlist (new check): register a non-allow-listed hosted redirect and assert it is rejected with 400 invalid_redirect_uri. The dashboard now positively verifies the CWE-601 open-registration phishing guard stays enforced on the live server.
• test harness: stubFetch now accepts a function route (backward-compatible) so one endpoint can answer by request body; the /oauth/register mock mirrors the allow-list (201 + client_id for loopback, 400 invalid_redirect_uri for a non-allow-listed hosted redirect). Both register checks are asserted.

Testing

• cargo build --locked --all-targets — not applicable (no Rust change)
• cargo test --locked --all-targets — not applicable (no Rust change)
• cargo fmt --all / cargo clippy --all-targets — not applicable (no Rust change)
• npm test --prefix monitoring/mcp-status — 17 passing (adds the allow-list assertion)

Checklist

• I have read the Contributing guidelines.
• Docs (README / comments) updated for any user-visible change.
• No secrets, credentials, or internal-only information are included.

🤖 Generated with Claude Code

https://claude.ai/code/session_014T9N8USDfNK5yzznPGg7Ym

---

Generated by Claude Code

[Copilot]

Pull request overview

Updates the status dashboard’s OAuth Dynamic Client Registration (DCR) probe to align with the hosted-redirect allow-list behavior, and adds a new probe that actively monitors that allow-list guard remains enforced.

Changes:

• Switch the existing DCR check to register a loopback redirect URI so it continues to validate “self-registration mints a client_id” without depending on hosted domains.
• Add a new check that verifies non-allow-listed hosted redirects are rejected with 400 invalid_redirect_uri.
• Extend the test harness stubFetch to support function-based routes and update /oauth/register mocking accordingly.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
monitoring/mcp-status/checks.js	Adjusts the DCR probe to use loopback redirect URIs and introduces a new allow-list enforcement check.
monitoring/mcp-status/checks.test.js	Enhances the fetch stub to support function routes and adds a registration mock that mirrors allow-list behavior; asserts the new check.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

monitoring/mcp-status/checks.test.js:73

• registerRoute aims to mirror the server’s is_loopback_redirect, but the JS check can incorrectly treat URLs with explicit empty userinfo as loopback (e.g. http://@127.0.0.1/cb or http://:@127.0.0.1/cb). The server rejects these because password().is_none() must hold (see src/auth.rs:1428-1432), while in the WHATWG URL API both username and password can be empty strings even when userinfo is present. Consider additionally rejecting any @ in the authority to ensure the mock matches the real guard.

    loopback =
      u.protocol === "http:" &&
      u.username === "" &&
      u.password === "" &&
      ["localhost", "127.0.0.1", "[::1]", "::1"].includes(u.hostname);