|
| Description: |
h2. Problem
The application ships 33 wiki pages, 19 21 of which carry script, and exactly one of them declares the
rights it requires: {{ReleaseNotes.Code.MigrationFrom1x}}, since RN-110.
A page that does Two separate things are missing.
*The pages do not enforce say what they need to run.* No {{enforceRequiredRights}} flag, no
{{XWiki.RequiredRightClass}} object. Enforcing required rights offers no guarantee about what its script is allowed to also what refuses edit on a
do, and — the part that matters here — nothing prevents document to a user who merely holds does not hold them, so its absence is what lets a user holding edit right on the
wiki from rewriting rewrite a code page . Any — and any right check a page performs in its own content only lasts as
long as
nobody rewrites that content. That was the reasoning behind RN-110; it is not specific to the
migration page.
Two separate things are missing:
* the pages do not say what they need to run: no The {{ enforceRequiredRights}} flag, no
{{XWiki.RequiredRightClass}} object. XWiki's own required-rights analyzer computes this per page and
should be the source of truth for the level, rather than a hand-derived guess.
* the {{ ReleaseNotes.Code}} space has no rights object, * so editing the application's code is open to
any user holding edit right. XWiki warns them ("Editing this page may result in breakage because you
are missing the following rights") and then offers a "Force editing" button. Restricting {{edit}} on
a {{*Code}} space to {{XWiki.XWikiAdminGroup}}
through a {{WebPreferences}} page is established
practice in XWiki Platform (for instance — 32 such rights objects across 11 modules, including
{{PanelsCode.WebPreferences}}, {{ReleaseCode.WebPreferences}} and
{{Image.Style.Code.ImageStyles.WebPreferences}} ) .
h2. Fix
Declare required rights on every page of the application , with at the level XWiki's own required-rights analyzer computes
for
it (asked page by page over {{/rest/.../requiredRights}} , rather than hand-derived), and ship a
{{ReleaseNotes.Code.WebPreferences}} page restricting {{edit}} and {{delete}} on
the code space to
wiki administrators.
*30 of the 34 pages end up enforcing:* 21 requiring {{script}}, 3 requiring {{wiki_admin}}
({{Code.ApplicationsPanelEntry}} for its wiki-scoped UI extension, {{Code.Translations}} for its
wiki-scoped translation bundle, and {{Code.MigrationFrom1x}} which keeps the level RN-110 gave it),
and 6 enforcing while requiring nothing at all, which is the strongest setting and stops a later
editor from introducing script into them.
h2. The four pages that cannot enforce
Two platform behaviours, both measured on XWiki 17.10.9, rule them out:
* enforcement caps the rights of whatever a page {{ {}{{include}}{}}}s, so it cannot be applied to one
page of an include chain and not the next;
* {{Document.checkRequiredRightsForSaving}} forces {{enforceRequiredRights}} onto every document an
enforcing page's script saves, capped at the rights that page declares.
{{ReleaseNotes.Data.WebHome}} is the secure document for the release - note creation. Enforcing it
therefore forced enforcement onto every release note created through the form, and since
{{Code.ReleaseNoteTemplate}} declares no required right for {{Code.HomeReleaseNotes}} to copy
(RN-68), the created note came back enforcing and requiring nothing — so the template's Velocity
stopped running and the note rendered its title as raw Velocity source, the defect RN-79 fixed.
Declaring {{script}} on the template fixes that but makes script right a condition of editing a
release note: a user holding only edit right could no longer edit the note they had just created,
nor add a change to it. That contradicts RN-30.
So {{ReleaseNotes.WebHome}}, {{ReleaseNotes.Data.WebHome}}, {{Code.HomeReleaseNotes}} and
{{Code.ReleaseNoteTemplate}} do not enforce. The two of them inside {{ReleaseNotes.Code}} are still
protected from being rewritten, by the new rights object. Taking the Velocity out of the release-note
template, so that a release note needs no rights at all and all four pages can enforce, is a change
to the creation flow and belongs in its own issue.
h2. No behaviour change
Verified on a running 17.10.9 for three profiles — wiki admin, edit + script, and edit only (what a
registered user gets in the standard flavor). All three can still view every page of the application
with no rendering error, create a release note, edit it, add a change to it, add contributors, and
read the four report displayers. What changed is that the last two are now refused edit on
{{ReleaseNotes.Code}}, and the 1.x migration stays wiki-administrator-only.
The {{- demo}} module is left alone on purpose: it is sample release-note content users are meant to
edit and delete, it carries no script, and enforcement there would only add friction.
|
| Attachment: |
rn111-after-note.png |
| Attachment: |
rn111-before-edit-code-page.png |
| Attachment: |
rn111-after-home.png |
| Attachment: |
rn111-before-note.png |
| Attachment: |
rn111-after-edit-code-page.png |
| Attachment: |
rn111-before-home.png |
|
