fix(api): Tighten alert mutation write scopes#113194
Closed
dcramer wants to merge 5 commits into
Closed
Conversation
github-actions
Bot
added
the
Scope: Backend
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Require project-scoped write access for alert-style mutation endpoints across alerts, monitors, workflow engine, seer, uptime, replays, and related API surfaces. This keeps the intended write-scope behavior while rebuilding the change directly on master instead of depending on the readonly-mutation-notes stack. Add regression coverage for token and team-admin scope checks, plus the endpoint-specific edge cases that surfaced while unstacking the branch. Co-Authored-By: OpenAI Codex <noreply@openai.com>
Keep missing alert-rule and detector detail lookups on the existing 404 path for project-scoped alerts:write callers. The permission helper now distinguishes a lookup miss from a view that does not participate in project-scoped alert checks, and the detail endpoint tests cover both the missing-target 404 and cross-project 403 behaviors. Co-Authored-By: OpenAI Codex <noreply@openai.com>
Continue the feedback pass by keeping workflow-engine detector lookups reachable from the organization alert-rule detail endpoint. The project-scoped permission helper now preserves the 404 behavior for real lookup misses without short-circuiting the detector fallback path, and the alert-rule detail tests cover the team-admin workflow-engine detector cases explicitly. Also fold the duplicated organization-id helper into a shared location and reuse the alert-rule permission implementation for detector endpoints to avoid the same drift in future changes. Co-Authored-By: OpenAI Codex <noreply@openai.com>
dcramer
force-pushed
the
dcramer/fix/api-write-scope-mutations-clean
branch
from
1d18443 to
aec2a3d
Compare
Route get_alert_mutation_projects through _get_organization_id so the\norganization-scoped alert permission check still works when auth token\nevaluation passes an RpcUserOrganizationContext.\n\nAdd a regression test for the RPC wrapper path so the mutation lookup\ndoes not silently return None again.\n\nCo-Authored-By: Codex <noreply@openai.com>
Return ALERT_MUTATION_LOOKUP_MISS for invalid and missing anomaly\npreview project IDs so project-scoped alerts:write callers follow the\nmissing-target path instead of falling through to team fallback.\n\nTighten the related permission narrowing and test annotations so the\nbackend typing job matches the runtime behavior again.\n\nCo-Authored-By: Codex <noreply@openai.com>
Contributor
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit eafc40f. Configure here.
| return Response( | ||
| {"detail": "You do not have permission to perform this action."}, | ||
| status=403, | ||
| ) |
Contributor
There was a problem hiding this comment.
Anomaly preview returns misleading 403 for nonexistent projects
Medium Severity
When a user with org-level write access (e.g., org:admin or org:write) passes the permission check via super().has_object_permission(), the get_alert_mutation_projects method is never called. If the project_id in the request body refers to a project that doesn't exist in the organization, the post() method now returns a 403 with "You do not have permission to perform this action." The old code returned a 400 with "Invalid project," which was more accurate — the user clearly has permission, the project just doesn't exist. This misleads authorized callers into thinking they lack access rather than having submitted an invalid project ID.
Reviewed by Cursor Bugbot for commit eafc40f. Configure here.
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.
1 participant
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.
Tighten project-scoped write checks for alert-style mutation endpoints that target a specific project.
This rebuilds the intended scope-tightening work from #113120 directly on
masterso it can land without the unrelated readonly-mutation-notes changes that were stacked into the old branch.The main change is to honor project-scoped
alerts:writeaccess consistently across alert-rule and detector mutations, monitor creation, uptime previews and suggestions, replay deletes, data export authorization, user issue mutation, and Seer anomaly preview requests. While tightening those checks, this keeps the established missing-target behavior for alert-rule and detector detail flows instead of turning stale or nonexistent targets into generic permission failures. The Seer anomaly preview follow-up also preserves lookup-miss handling when the permission layer receives anRpcUserOrganizationContext.This also updates regression coverage around project-scoped writers, missing targets, cross-project access, and the anomaly-preview permission path so the permission logic and endpoint behavior stay aligned.
The optional OpenAPI schema-diff check is expected on this PR because these permission changes intentionally update the documented security requirements for the affected endpoints.
Supersedes #113120.