feat(dashboard): add dry_run query param to PUT /dashboard/<pk>/colors#40282
feat(dashboard): add dry_run query param to PUT /dashboard/<pk>/colors#40282chloetkl wants to merge 1 commit into
Conversation
Adds a `dry_run` boolean query parameter to the colors config update endpoint. When set to true, the request is validated and a 200 is returned without persisting any changes to the dashboard.
dosubot
Bot
added
api:dashboard
Code Review Agent Run #3d44e8Actionable Suggestions - 0Filtered by Review RulesBito filtered these suggestions based on rules created automatically for your feedback. Manage rules.
Review Details
Bito Usage GuideCommands Type the following command in the pull request comment and save the comment.
Refer to the documentation for additional commands. Configuration This repository uses Documentation & Help AI Code Review powered by |
✅ Deploy Preview for superset-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
![codeant-ai-for-open-source[bot]](https://avatars.githubusercontent.com/u/151810221?s=60&v=4){kind=small}
| if dry_run: | ||
| response = self.response(200) | ||
| else: | ||
| UpdateDashboardColorsConfigCommand(pk, item, mark_updated).run() |
There was a problem hiding this comment.
🟠 Architect Review — HIGH
When dry_run=true, put_colors returns 200 without invoking UpdateDashboardColorsConfigCommand.run(), so dashboard existence and ownership checks are skipped and dry-run requests can succeed for nonexistent or unauthorized dashboards instead of returning 404/403 as in the normal path.
Suggestion: Keep dry_run non-persistent but still execute the command-level validation path (for example by calling UpdateDashboardColorsConfigCommand(...).validate() or an equivalent validate-only command) so that 404/403 are raised as usual while skipping the actual write.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is an **Architect / Logical Review** comment left during a code review. These reviews are first-class, important findings — not optional suggestions. Do NOT dismiss this as a 'big architectural change' just because the title says architect review; most of these can be resolved with a small, localized fix once the intent is understood.
**Path:** superset/dashboards/api.py
**Line:** 1065:1068
**Comment:**
*HIGH: When dry_run=true, put_colors returns 200 without invoking UpdateDashboardColorsConfigCommand.run(), so dashboard existence and ownership checks are skipped and dry-run requests can succeed for nonexistent or unauthorized dashboards instead of returning 404/403 as in the normal path.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
If a suggested approach is provided above, use it as the authoritative instruction. If no explicit code suggestion is given, you MUST still draft and apply your own minimal, localized fix — do not punt back with 'no suggestion provided, review manually'. Keep the change as small as possible: add a guard clause, gate on a loading state, reorder an await, wrap in a conditional, etc. Do not refactor surrounding code or expand scope beyond the finding.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
|
The PR comments file contains only one comment thread with the architectural review suggestion. The suggestion recommends validating dashboard existence and ownership during dry-run requests by executing command-level validation without persisting changes. This would ensure proper 404/403 responses for invalid/unauthorized dashboards even in dry-run mode. superset/dashboards/api.py |
| if dry_run: | ||
| response = self.response(200) | ||
| else: | ||
| UpdateDashboardColorsConfigCommand(pk, item, mark_updated).run() | ||
| response = self.response(200) |
There was a problem hiding this comment.
Suggestion: The dry_run branch skips UpdateDashboardColorsConfigCommand.run(), which is where dashboard existence and ownership checks happen. That causes dry_run=true requests to return 200 even for non-existent dashboards or dashboards the caller is not allowed to modify. Keep the same validation/authorization path for dry runs (for example, add a dry-run mode to the command that runs validation but skips persistence). [security]
Severity Level: Critical 🚨
- ❌ Dry-run colors endpoint returns 200 for nonexistent dashboard IDs.
- ❌ Dry-run bypasses DashboardDAO existence and raise_for_ownership validations.
- ⚠️ Clients may accept invalid dashboard colors config as valid.Steps of Reproduction ✅
1. Start Superset with this PR code and note the dashboard colors update endpoint
`put_colors` defined in `superset/dashboards/api.py` at lines 10-85 of the snippet
returned by Read (header "Showing lines 1000 to 1199"), exposed via
`@expose("/<pk>/colors", methods=("PUT",))` inside `DashboardRestApi`.
2. Send an HTTP `PUT` request to `/api/v1/dashboard/<pk>/colors?dry_run=true` with a valid
JSON body (so Marshmallow validation in `put_colors` at `api.py` lines 56-59 passes), but
choose `<pk>` to be a dashboard ID that does not exist in the database (or one the current
user does not own).
3. The request enters `DashboardRestApi.put_colors` (`api.py` lines 56-85); inside the
second `try:` block at lines 61-70, `dry_run` is parsed as `True`, so the branch at lines
66-70 executes: `if dry_run: response = self.response(200)` and the method returns without
ever invoking `UpdateDashboardColorsConfigCommand(pk, item, mark_updated).run()`.
4. Because `UpdateDashboardColorsConfigCommand.run()`
(`superset/commands/dashboard/update.py` lines 40-63) calls `super().validate()` which in
turn runs `UpdateDashboardCommand.validate` (`update.py` lines 42-88) to (a) look up the
dashboard via `DashboardDAO.find_by_id(self._model_id)` and raise
`DashboardNotFoundError()` if missing, and (b) enforce ownership via
`security_manager.raise_for_ownership(self._model)` raising `DashboardForbiddenError()` on
failure, skipping `run()` in the dry-run branch means none of these checks execute, no
exception is raised, and the client receives HTTP 200 instead of the expected 404/403 for
nonexistent or unauthorized dashboards.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** superset/dashboards/api.py
**Line:** 1065:1069
**Comment:**
*Security: The `dry_run` branch skips `UpdateDashboardColorsConfigCommand.run()`, which is where dashboard existence and ownership checks happen. That causes `dry_run=true` requests to return 200 even for non-existent dashboards or dashboards the caller is not allowed to modify. Keep the same validation/authorization path for dry runs (for example, add a dry-run mode to the command that runs validation but skips persistence).
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix1 participant
Adds a
dry_runboolean query parameter to the colors config update endpoint. When set to true, the request is validated and a 200 is returned without persisting any changes to the dashboard.