Repository navigation
fix: accept only Prividium sessions issued to the explorer on login and the REST API - #673
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
API E2E Test Results185 tests 185 ✅ 9s ⏱️ Results for commit 6cb225d. ♻️ This comment has been updated with latest results. |
API Prividium E2E Test Results22 tests 22 ✅ 4s ⏱️ Results for commit 6cb225d. ♻️ This comment has been updated with latest results. |
Unit Test Results 4 files 288 suites 8m 30s ⏱️ Results for commit 6cb225d. ♻️ This comment has been updated with latest results. |
|
Visit the preview URL for this PR: |
…light verifications
|
Visit the preview URL for this PR: |
|
Visit the preview URL for this PR: |
|
Visit the preview URL for this PR: |
jodator
left a comment
jodator
left a comment
There was a problem hiding this comment.
No blockers from me. The main ask is the new dependency of data routes on the permissions API auth rate limit, inline on auth.middleware.ts and explorerSession.ts. The rest are PR body claims, tests and nits.
Record verified audiences in signed cookies, reject junk tokens before the auth lookup, and cache confirmed foreign audiences within the shared bound. Cover retries, cookie migration, M2M isolation, and foreign-cookie RPC rejection.
|
Visit the preview URL for this PR: |
|
Visit the preview URL for this PR: |
|
Visit the preview URL for this PR: |
|
🎉 This PR is included in version 3.32.2 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
3 participants
What ❔
Reject Prividium user sessions issued to another application at explorer login, on the REST bearer path, and behind existing explorer cookies.
GET /api/auth/current-sessionmust identify an account session (oauthClientIdnull or absent) or the explorer's own session (block-explorer). Other session types and audiences are rejected.audienceChecked: truein the signed cookie. Existing cookies receive this marker after their first successful audience check./rpc./auth/mecontinues to reflect the cookie without calling the permissions API.x-api-keydo not call the session verifier.Caching and availability. One shared verifier caches accepted and confirmed foreign-audience verdicts until session expiry, within a combined 10,000-entry limit. Concurrent requests for the same token share one upstream call. Repeated foreign-token logins also reuse the rejection. Accepted logins fetch fresh expiry; upstream 401/403 responses, throttling, and network/server failures remain uncached.
New logins, uncached bearer tokens, and unmarked legacy cookies still require available upstream auth capacity. Established, marked cookies do not depend on
current-sessionfor data requests.Authorization. This caches only immutable session type and audience. Existing cookie expiry and live authorization checks remain in place. REST bearer requests, Swagger, and routes using
AddUserRolesPipecheck the live profile;/rpcrelies on upstream RPC authorization. Cookie routes without a live lookup, such as/blocks,/stats, and the token list, can remain readable until cookie session expiry after upstream revocation. This matches their behavior before this PR.Failure handling. A 429 or 5xx from
current-sessionis an upstream failure: 500 on login and 502 in the middleware or Swagger gate. The frontend logs out only on 401/403 and preserves the cookie on transient failures.Why ❔
The explorer previously accepted application-scoped sessions without comparing their OAuth client to its own. A token obtained through another application's "Login with Prividium" flow could therefore become an explorer cookie or access the indexed chain through the REST API.
The audience check closes that path. Cookie markers, profile-first login, and bounded verdict caching keep repeated invalid attempts from adding an auth-rate-limit dependency to established cookie sessions.
Compatibility and rollout
oauthClientIdand give applications account sessions, so every user session passes this check, including tokens obtained through other applications. Upgrade those deployments for the fix to provide audience isolation.Evidence
--testTimeout=30000./rpcand cookie migration during upstream failure.git diff --checkpassed.POST /api/applications; its server-generated client ID wask5PIekVFOcikkxxa. Explorer and third-party sessions were issued through/api/auth/application-session.POST /auth/loginoauthClientId: nulloauthClientId: "block-explorer"oauthClientId: "k5PIekVFOcikkxxa"The real contract check covers backend login and session responses; it does not exercise browser OAuth redirects. Its test sessions were revoked afterwards. Normal admin-panel login receives an account session without an application audience, which the explorer intentionally accepts.
Checklist