This repository was archived by the owner on Jul 2, 2026. It is now read-only.
Scope admin configuration changes to the target configuration - #582
Closed
ahmedhamouda78 wants to merge 1 commit into
Closed
Conversation
Member
Author
|
Superseded by the same-repo branch so CI runs with repository secrets: #583 |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
Several
/api/adminendpoints act on a configuration identified by an id in therequest body (
configurationId/id), but they do not re-evaluate the caller'saccess against that configuration. Access (
isAdmin) is derived from the caller'sactive guild (session), which may differ from the configuration being changed. This
is inconsistent with how access is determined elsewhere in the app and means these
endpoints can operate on a configuration other than the one the caller's access was
evaluated for.
This change evaluates the caller's access against the configuration each endpoint
actually modifies, using the existing
getUserAccesshelper (the same one thesession callback uses). Because a configuration's id is the guild id, access can be
resolved directly from the id in the request.
Changes
src/lib/server/require-configuration-admin.tsexportingisConfigurationAdmin(discordUserId, configurationId), which resolves access forthe target configuration and returns whether the caller is an admin. Non-members
of the target guild resolve to
false.POST /api/admin/feature: require an authenticated session and admin access forconfigurationIdbefore updating features (401when unauthenticated,403when the caller does not administer the target configuration).
POST /api/admin/configure: require the same before creating/updating aconfiguration and its role mappings. Onboarding is preserved —
getUserAccessfalls back to guild-owner status when no configuration exists yet, so a guild
owner can still create their configuration.
DELETE /api/admin/configure: require the same before deleting a configuration.No changes to
POST/PUT/DELETE /api/admin/commandsorGET /api/admin/is: theseoperate on the caller's active guild (
locals.guildId) or are read-only, so theobject acted on already matches the guild access was evaluated for.
Testing
configuration returns
403; unauthenticated requests return401.