Pin the Schema name search read gate and correct the permissions docs#1071
Draft
JeroenDeDauw wants to merge 2 commits into
Draft
Pin the Schema name search read gate and correct the permissions docs#1071JeroenDeDauw wants to merge 2 commits into
JeroenDeDauw wants to merge 2 commits into
Conversation
Both existing denial tests call getSchemaNamesMatching with an empty
search, so they only cover getFirstSchemaNames. Deleting filterReadable
from the search branch -- the branch GET /schema-names/{search} actually
uses -- passed the whole suite.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The Permissions section claimed that page protection and restricted namespaces apply to reads. Neither does: for the read action MediaWiki runs only checkPermissionHooks, checkReadPermissions and checkUserBlock, read is not one of the default $wgRestrictionTypes, and $wgNamespaceProtection is only consulted by checkSpecialsAndNSPermissions, which reads skip. Per-page read restrictions come from $wgWhitelistRead or a permission extension. It also stated without qualification that read endpoints enforce per-page read permission. GET /subject-labels applies no per-page filter, so on a restricted wiki it still answers with the labels and ids of Subjects on pages the caller may not read, and the totalRows counts still include rows omitted from the list. Restore those caveats, which #1046 lists as documented here and which each have a follow-up issue. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Follows-up to #1058
Two fixes from an AI review of #1058. Both are small. The review's more significant findings are deliberately not in this branch — they need your call, and are reported separately.
Test the read gate on the Schema name search branch
Both denial tests in
DatabaseSchemaNameLookupTestcallgetSchemaNamesMatchingwith an empty search, so they only covergetFirstSchemaNames. DeletingfilterReadablefrom the search branch — the oneGET /schema-names/{search}actually uses — passed the full suite. The production code is correct; the gate was simply unpinned. The new test fails without the gate and passes with it.Correct the REST permissions documentation
Two inaccuracies:
readaction MediaWiki runs onlycheckPermissionHooks,checkReadPermissionsandcheckUserBlock;readis not one of the default$wgRestrictionTypes; and$wgNamespaceProtectionis only consulted bycheckSpecialsAndNSPermissions, which reads skip. Per-page read restrictions come from$wgWhitelistReador a permission extension.read.GET /subject-labelsapplies no per-page filter. Verified on a dev wiki with one page read-denied:GET /subject/{id}returns{"subject":null}whileGET /subject-labelsstill returns that Subject's id and label.totalRowslikewise still counts rows omitted from the list.This partially restores caveats that 4cb79db trimmed as "temporary not-yet caveats". Flagging rather than assuming your intent: #1058's description says the deferred gaps are "Documented in the new
docs/api/rest-api.mdPermissions section", and the trim removed exactly that, which left the remaining blanket claim false. If you prefer different wording, the only constraint is that the section not assert a guarantee/subject-labelsdoes not provide.Verification
make csclean; full suite green (1689 tests). New test proven load-bearing by mutation.