security(core): scope auth tokens with explicit CRUD permissions and server-assigned login (24.05) - #7964
Open
ar2rsawseen wants to merge 1 commit into
Open
Conversation
…server-assigned login Token scope was expressed as an app list and an endpoint regex, which verify_token compared against the request path and, when present, the request's app_id. That is a data-scoping control: it does not describe what the resolved member may do, and rights.js did not carry it past token resolution, so a token authorized whatever its owner could. Login capability was likewise inferred from the token's purpose string, which is supplied by the caller at creation. Tokens now carry explicit permissions and an explicit login capability. - token_permission stores a member.permission-shaped grant on the token. rights.js intersects it with the owner's own permissions as soon as the member is loaded, before any validator authorizes anything, so every existing feature check becomes scope-aware without being touched. The intersected member does not carry global_admin. The intersection is recomputed per request, so it follows the owner's current permissions. - A grant is bounded by the credential that creates it, not by the owner. Because the intersection has already happened, params.member is that credential's authority, and isPermissionSubset refuses anything wider. An "all" grant may only be passed on by a holder of "all", since it covers features that do not exist yet. - can_login is a server-assigned property of the token. It is set where the server establishes or propagates a session (setLoggedInVariables, the renderer, the ban-warning mail), and by /i/token/create only when the creating credential holds it and the child is not narrowed. purpose returns to being a description. - Token creation, listing and deletion require a full-permission credential, since each of them hands out, exposes or revokes the owner's credentials. This branch also takes hasAdminAccess from 5e60144, which is on later versions but was never backported here. It treated an app with no permission entry for the member as one they administer. The permission model depends on that being correct, since an intersected member expresses "no access" as the absence of an entry. Tokens created before this change are unaffected: with no token_permission they are neither intersected nor re-scoped, the endpoint regex still applies to them, and /login/token still accepts the unrestricted login-purpose tokens it accepted previously. The token manager grants app, CRUD and feature permissions using the same permission grid and helpers as user management, instead of endpoint regexes. Covered by unit tests for the permission algebra and the token record, and by API tests for the create, login, list and delete boundaries. Reported through the security bug bounty program (received 2026-08-18). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Backport of #7963 to
release.24.05.Replaces the token
app/endpointscoping model with explicit CRUD permissions, and makes permission to open a dashboard session an explicit, server-assigned property of the token. See #7963 for the full description of the model.One addition specific to this branch
This backport also takes
hasAdminAccessfrom5e6014496da(SER-2766), which is on later versions but was never backported here. On this branch it treats an app with no permission entry for the member as one they administer, becauseisAdminstarts astrueand is only cleared when an entry exists and is notall.That has to be corrected for the permission model to mean anything here: an intersected member expresses "no access to app B" as the absence of an entry for B, which this branch would otherwise read as administering B. It is also reachable independently of tokens, since
validateUserForWritegates solely onhasAdminAccess.Verified on this branch before and after: a member with access to app A only previously returned
truefromhasAdminAccess(member, B),hasReadRight('core', B, member)andhasDeleteRight('core', B, member); all now returnfalse, while legitimate access to A is unchanged.Verification
Ported by cherry-pick; three conflicts resolved by hand (the
rights.jsimport list, which lacksgetBaseAppFilterhere, and the CHANGELOG and localization sections, which differ from master).The same 21 unit tests pass on this branch. The 5 unrelated failures in
api.utils.common.jsandapi.utils.countly-request.jsare pre-existing onrelease.24.05and fail identically without this change.Related
master: security(core): scope auth tokens with explicit CRUD permissions and server-assigned login #7963Supersedes the earlier containment PR #7958, closed in favour of this model.
Reported through the security bug bounty program (received 2026-08-18).
🤖 Generated with Claude Code