You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Fix download MCP blocked when toggle was off - #3569
___________________________________________________________
< Your API returns 200 OK; your users return 404 Not Found. >
-----------------------------------------------------------
\
\ \
\ /\
( )
.( o ).
✨ Finishing Touches
📝 Generate docstrings
Commit to this branch
Create a new PR
🧪 Generate unit tests (beta)
Commit to this branch
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
We reviewed changes in 1c85367...2115081 on this pull request. Below is the summary for the review, and you can see the individual issues we found as inline review comments.
AI Review is run only on demand for your team. We're only showing results of static analysis review right now. To trigger AI Review, comment @deepsourcebot review on this thread.
The reason will be displayed to describe this comment to others. Learn more.
Approve. The download handler now saves the submitted MCP toggle (only after the permission and nonce checks), resets the memoized is_enabled(), and loads the adapter, so an unsaved "on" toggle no longer gets a 403 from the Download button.
Live check: ran the PR's new test_download_saves_submitted_mcp_setting (6 scenarios: unsaved on, unchecked, nothing posted, no marker, bad nonce, subscriber) under PHPUnit. It passes with the PR (4 tests, 62 assertions) and fails with the base FrmMcpSkillEnvController.php swapped back in. The failure text came out garbled by a harness quirk, so I can't say which scenario failed.
Not exercised: the real Download click in a browser. The Playground env isn't treated as local, so Application Passwords are unavailable and the button doesn't render. The success path (credential created, file streamed) isn't covered either, since the tests stop at the 403 before the file response.
Not run:security-review/simplify (two-file diff, read in full instead), PHPCS/PHPStan locally.
Non-blocking:
A failed download still keeps the toggle change. If Application Passwords are off or the site isn't HTTPS, the user sees the 403 page and MCP is now saved as on, without ever pressing Save. The test asserts this, so it looks intended, but it's worth a deliberate yes.
FrmSettings::update_settings() (L661) has the same "marker present, then empty( frm_mcp ) ? 0 : 1" rule. This copies it into a second place, so the two can drift. Consider a small shared method on FrmSettings.
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
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.
This fixes a bug I noticed, where the download button would fail if the toggle wasn't saved yet.