Gate POST /api/v1/publishing/retry and /push with requiredPortlet("publishing-queue")

[hmoreras]

Description

Two state-changing endpoints on PublishingResource currently authenticate the backend user but do not check portlet access:

• POST /api/v1/publishing/retry — re-queues one or more bundles for publishing
• POST /api/v1/publishing/push/{bundleId} — schedules a bundle push to one or more environments

Their sibling destructive endpoints already gate on requiredPortlet("publishing-queue"):

• DELETE /api/v1/publishing/{bundleId} — PublishingResource.java:489
• DELETE /api/v1/publishing/purge — PublishingResource.java:954

Impact: any authenticated backend user (even one whose role is intentionally denied access to the Publishing Queue portlet in the admin UI) can call these two endpoints directly via curl / Postman / the browser console and cause real push work to fire on remote environments.

The fix is one line per endpoint — add .requiredPortlet("publishing-queue") to the WebResource.InitBuilder chain. But it needs a team review first because it narrows access for the small set of backend users who have API access but no explicit Publishing Queue portlet grant.

Acceptance Criteria

To be refined. (Quick draft — details to be added after team confirms scope.)

• Confirm with team whether narrowing access via portlet gate is the correct behavior
• Add .requiredPortlet("publishing-queue") to retryBundles (PublishingResource.java:602) and pushBundle (:760) if approved
• Update Postman coverage to assert 403 for a user without the portlet grant

Priority

Medium — no known exploit path from the shipped UI (the UI only reaches these endpoints from the portlet the user already has access to). This closes a defense-in-depth gap for direct API callers.

Additional Context

The inconsistency was surfaced during code review of the Publishing Queue Angular migration.

[github-actions]

PRs linked to this issue

• fix(publishing): enforce environment USE permission on retry and restrict getunsendbundles to owner (#36414, #36415) by @hassandotcms

[hmoreras]

QA Verified ✅

Ran manual QA against a local push-publish stack (sender localhost:8081) using the dotcms/dotcms:modernization image built from f574a9de4a. Confirmed PR #36446 (bce3f77) is present in the image via class-string markers (validateRetryEnvironmentPermissions, does not have permission to use environment, is not allowed to list bundles owned by).

Test setup

• Two non-admin backend users granted the Site layout (publishing-queue portlet)
• Push environment with whoCanSend=[UserA_role] (UserA has USE, UserB does not)
• Bundle linked to the environment with audit status FAILED_TO_PUBLISH(8)

Results

#	Scenario	Expected	Actual	Verdict
1	GET /api/bundle/getunsendbundles/userid/{self} as UserA	200	200	✅
2	GET /api/bundle/getunsendbundles/userid/{userB} as UserA	403	403 — User 'qa36414-usera2' is not allowed to list bundles owned by user 'qa36414-userb'	✅
3	GET /api/bundle/getunsendbundles/userid/{userB} as admin	200	200	✅
4	POST /api/v1/publishing/retry as UserB (no USE)	200 w/ success=false + permission-denied message	200, success=false, User 'qa36414-userb' cannot push bundle '…' because it does not have permission to use environment 'qa36414-env'	✅
5	POST /api/v1/publishing/retry as UserA (has USE)	Auth check passes; may fail downstream	200, success=false, Bundle file not found (downstream, auth passed)	✅
6	POST /api/v1/publishing/retry as admin	Admin bypasses auth	200, success=false, Bundle file not found (admin bypassed auth)	✅

Scope notes

• The delivered fix uses a per-environment PERMISSION_USE check on retry rather than the portlet gate this issue originally proposed. That is tighter than the AC (a user with the portlet but no USE on a specific environment is now blocked from retry). Behavior looks correct and consistent with how push already enforces the same check.
• POST /api/v1/publishing/push/{bundleId} was not modified by PR fix(publishing): enforce permission on retry and restrict getunsendbundles to owner (#36414, #36415) #36446 — the PR body notes push already enforces USE via PublishingJobsHelper#validateEnvironmentPermissions. Not exercised in this pass.
• PR fix(publishing): enforce permission on retry and restrict getunsendbundles to owner (#36414, #36415) #36446 also closes Security: /api/bundle/getunsendbundles does not verify the path userId matches the authenticated user #36415 (getunsendbundles owner check) — cases 1–3 verify that.

Closing this out — all cases pass.