Add TS admin endpoint to look up EC by id

[prk-Jr]

Summary

• Adds GET /_ts/admin/ec/{id} (explicit EC ID) and GET /_ts/admin/ec (EC ID from the caller's ts-ec cookie) so operators can inspect EC identity graph entries without KV console access.
• The EC response includes a derived auction view: the exact EIDs the auction would attach for the entry, plus the reason each stored partner ID was skipped (empty_uid, not_in_registry, bidstream_disabled) — making KV-to-auction EID propagation debuggable in one call. Corrupt or legacy-schema entries stay inspectable via a new raw lookup that reports entry_error + raw_body instead of failing closed.
• Adds GET /_ts/admin/eids, the client-side half of the picture: it echoes the request's ts-eids and sharedId cookies and previews what cookie ingestion would write into the EC entry's ids map (matched partner UIDs, deduplicated exactly like the ingestion path, plus dropped sources). Pure request inspection with no KV access, so every adapter serves the real handler; always responds 200.

Changes

File	Change
crates/trusted-server-core/src/ec/admin.rs	New handle_admin_ec_lookup + handle_admin_eids_lookup handlers, response payload types, 14 unit tests
crates/trusted-server-core/src/ec/kv.rs	New KvIdentityGraph::lookup_raw returning raw body/metadata/generation without validation
crates/trusted-server-core/src/ec/prebid_eids.rs	Expose cookie-ingestion collectors pub(crate) so the EIDs preview reuses them instead of reimplementing
crates/trusted-server-core/src/ec/mod.rs	Register admin module
crates/trusted-server-core/src/settings.rs	Add all three routes to Settings::ADMIN_ENDPOINTS; update coverage tests
crates/trusted-server-adapter-fastly/src/app.rs	Route EC + EIDs paths to the real handlers; route-table tests. The EC arm deliberately builds its own identity graph instead of reusing the bot-gated ec.kv_graph, so operator curl requests work
crates/trusted-server-adapter-axum/src/app.rs	EC routes → local 501 (AdminEcNotSupported); EIDs route → real handler
crates/trusted-server-adapter-axum/tests/routes.rs	Route-registration, authenticated-501 (EC) and authenticated-200 (EIDs) tests
crates/trusted-server-adapter-cloudflare/src/app.rs	EC routes → local 501; EIDs route → real handler
crates/trusted-server-adapter-cloudflare/tests/routes.rs	Route-registration, authenticated-501 (EC) and authenticated-200 (EIDs) tests
crates/trusted-server-adapter-spin/src/app.rs	EC routes → local 501; EIDs route → real handler; extend fallback-methods table
crates/trusted-server-adapter-spin/tests/routes.rs	Authenticated-501 (EC) and authenticated-200 (EIDs) tests

Closes

Closes #921

Test plan

• cargo test-fastly && cargo test-axum (also cargo test-cloudflare && cargo test-spin)
• cargo clippy-fastly && cargo clippy-axum (also clippy-cloudflare, clippy-cloudflare-wasm, clippy-spin-native, clippy-spin-wasm)
• cargo fmt --all -- --check
• JS tests: cd crates/trusted-server-js/lib && npx vitest run (JS untouched — left to CI)
• JS format: cd crates/trusted-server-js/lib && npm run format (JS untouched — left to CI)
• Docs format: cd docs && npm run format (docs untouched — left to CI)
• WASM build: cargo check -p trusted-server-adapter-fastly --target wasm32-wasip1
• Manual testing via fastly compute serve: verified auth gating, the EC lookup against the seeded Viceroy entry, and the EIDs echo against real browser cookies; this surfaced (and the branch fixes) an initial bug where the bot-gated KV graph made curl requests return 501
• Other: integration parity suite (cargo test --manifest-path crates/trusted-server-integration-tests/Cargo.toml --test parity)

Hardening note

All three paths were added to Settings::ADMIN_ENDPOINTS, so startup validation fails closed (a Configuration error via Report, no panic!/unwrap()/expect()) for any config whose basic-auth handler regex does not cover them; prefix-style regexes like the example config's ^/_ts/admin remain valid. Covered by the updated uncovered_admin_endpoints_* and admin_endpoints_match_fastly_router tests. Routes are registered explicitly on every adapter so they never fall through to the publisher fallback, which would forward the caller's Authorization header to the origin.

Checklist

• Changes follow CLAUDE.md conventions
• No unwrap() in production code — use expect("should ...")
• Uses log macros (not println!)
• New code has tests
• No secrets or credentials committed

[ChristianPavilonis]

Summary

Request changes. This adds sensitive admin diagnostics, but the current route/auth wiring permits an authentication bypass and can forward admin credentials to the publisher origin. The inline comments also cover Fastly-only write side effects, loss of raw KV data, and the missing operator API contract.

[ChristianPavilonis]

Automated Review:

Summary

Reviewed the admin EC/EID lookup routes, cross-adapter registration, KV handling, response behavior, and authorization validation. I found one high-severity authorization-coverage gap for the parameterized EC lookup route.

Findings by severity

P0 / Blockers

None.

P1 / High

One inline finding.

P2 / Medium

None.

P3 / Low

None.

CI / Existing Reviews

The displayed CI check runs for head 866bcd4c24be67ca5434fff82727375fbdfc5a45 are successful. Immediately before submission, the PR had no existing reviews or inline review comments. Local tests were not run during this review.

[ChristianPavilonis]

Summary

Requesting changes: the Fastly admin EC GET lookup currently runs the mutating EC finalization lifecycle. I also found an incomplete dynamic-route auth-coverage validation and a documentation mismatch for authentication failures.

The currently displayed PR checks are passing. I reviewed existing inline feedback and did not repeat items resolved at the current head.

[ChristianPavilonis]

P1 — Admin EC GET lookups are not read-only. This early return exempts only AdminEidsLookup; AdminEcLookup continues through build_ec_request_state and response finalization. A browser-shaped authenticated lookup carrying ts-eids/sharedId can therefore ingest those values into the caller's EC row, and a withdrawal signal can write a tombstone and trigger pull sync. A diagnostic GET should not mutate identity state.

Please dispatch AdminEcLookup before EC setup as well (while constructing its KV graph directly), and add a regression test that a cookie-bearing lookup response carries no EcFinalizeState and produces no KV write.

[prk-Jr]

Fixed in f3776a9, with the regression assertion tightened in 436e25f. execute_named now dispatches both admin diagnostics before request filters, EC setup, and finalization, and constructs the EC lookup graph directly. The browser-shaped cookie regression confirms that the handler runs, no EcFinalizeState is attached, and no Set-Cookie mutation is emitted; without finalization state, cookie ingestion, tombstone writes, and pull sync cannot run.

[ChristianPavilonis]

P2 — A single fixed probe does not prove coverage of the dynamic route. For example, a handler matching ^/_ts/admin/ec/[a-f0-9]{64}[.][a-z]{6}$ accepts this .abc123 probe and lets startup succeed, but valid EC IDs whose alphanumeric suffix contains a digit or uppercase character later fail closed as a configuration 500.

Require coverage of the complete dynamic ID language (or at least validate a character-class corpus including uppercase and numeric suffixes) and add a mixed-case/digit regression case.

[prk-Jr]

Fixed in de61c43. Dynamic EC auth coverage now probes both a lowercase suffix (.abc123) and a mixed-case/digit suffix (.Ab12Z9), and startup requires every probe to match. The added regression rejects a lowercase-only handler while the valid alphanumeric handler fixture covers both probes.

[ChristianPavilonis]

P3 — The documented response contract excludes authentication failures. The shared Basic-auth middleware returns a plaintext 401 Unauthorized response without Cache-Control: no-store, so it is not JSON/no-store as this sentence says. Please either qualify this statement to successful diagnostic-handler responses or update the auth response to meet the documented contract.

[prk-Jr]

Fixed in be434c2 and refined in 436e25f. The documentation now limits the JSON and no-store contract to normal diagnostic-handler responses after successful authentication, and explicitly documents the shared plaintext 401 challenge plus unexpected plaintext 5xx responses as outside that contract.

[aram356]

Summary

Adds three basic-auth-gated diagnostics (GET /_ts/admin/ec[/{id}], GET /_ts/admin/eids) plus admin-namespace hardening (fail-closed startup coverage, runtime fail-closed auth for unmatched admin paths, publisher-fallback denial). The hardening work and cross-adapter test coverage are in good shape, but the Fastly EC lookup still runs the mutating EC finalization lifecycle, the auth-coverage probe under-represents the EC ID language, and the documented response contract is inaccurate for 401s.

Blocking

🔧 wrench

• EC lookup GET is not read-only: AdminEcLookup still flows through build_ec_request_state, request filters, and EC finalization; a browser-shaped authenticated lookup ingests the caller's ts-eids/sharedId cookies into KV and can contaminate the very record being inspected (crates/trusted-server-adapter-fastly/src/app.rs:595)
• Auth-coverage probe misses mixed-case EC IDs: a handler regex matching only lowercase suffixes passes startup but produces ID-dependent runtime 500s (crates/trusted-server-core/src/settings.rs:2221)
• Docs overstate the response contract: the 401 challenge is plaintext without Cache-Control: no-store (docs/guide/api-reference.md:586)

Non-blocking

🤔 thinking

• Ingest preview drops partner-matched sources with no valid UID: they appear in neither matched nor unmatched, hiding the exact failure mode operators would debug (crates/trusted-server-core/src/ec/admin.rs:489)

♻️ refactor

• Third copy of extract_cookie_value in core: hoist to a shared helper (crates/trusted-server-core/src/ec/admin.rs:516)

⛏ nitpick

• Missing X-Content-Type-Options: nosniff on the shared admin JSON builder (crates/trusted-server-core/src/ec/admin.rs:537)
• tombstone doc comment incomplete: also absent on schema-deserialization failure (crates/trusted-server-core/src/ec/admin.rs:114)
• No unauthenticated 401 test for the new routes: every new-route adapter test sends valid credentials; the existing 401 tests cover only the keys routes. Given this PR's hardening story is auth coverage, one GET /_ts/admin/ec → 401 test per adapter would pin it.

📝 note

• Deliberate breaking config change: configs whose admin handler covers only the keys endpoints (e.g. ^/_ts/admin/keys/) now fail startup. Correct fail-closed behavior, but worth an explicit upgrade/release note so operators are not surprised at deploy time.

CI Status

• fmt: PASS
• clippy: PASS
• rust tests (fastly/axum/cloudflare/spin/parity/CLI): PASS
• js tests: PASS
• docs/format checks: PASS