Skip to content
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
aws-amplify:mainfrom
ahmedhamouda78:fix/scope-admin-configuration-changes-to-target
Closed

Scope admin configuration changes to the target configuration#582
ahmedhamouda78 wants to merge 1 commit into
aws-amplify:mainfrom
ahmedhamouda78:fix/scope-admin-configuration-changes-to-target

Conversation

@ahmedhamouda78

Copy link
Copy Markdown
Member

Summary

Several /api/admin endpoints act on a configuration identified by an id in the
request body (configurationId / id), but they do not re-evaluate the caller's
access against that configuration. Access (isAdmin) is derived from the caller's
active 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 getUserAccess helper (the same one the
session callback uses). Because a configuration's id is the guild id, access can be
resolved directly from the id in the request.

Changes

  • Add src/lib/server/require-configuration-admin.ts exporting
    isConfigurationAdmin(discordUserId, configurationId), which resolves access for
    the 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 for
    configurationId before updating features (401 when unauthenticated, 403
    when the caller does not administer the target configuration).
  • POST /api/admin/configure: require the same before creating/updating a
    configuration and its role mappings. Onboarding is preserved — getUserAccess
    falls 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/commands or GET /api/admin/is: these
operate on the caller's active guild (locals.guildId) or are read-only, so the
object acted on already matches the guild access was evaluated for.

Testing

  • Manual: as an admin of guild A, changing A succeeds; changing another guild's
    configuration returns 403; unauthenticated requests return 401.
  • Automated authorization coverage for these endpoints to follow.

Draft — opening for early review while validation is completed.

@ahmedhamouda78

Copy link
Copy Markdown
Member Author

Superseded by the same-repo branch so CI runs with repository secrets: #583

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant