Image editor on Image/File fields does not enforce permissions on the referenced dotAsset
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 970
- Forks
- 486
- Avg merge
- 3d 33m
- Merged PRs (30d)
- 170
Description
Problem Statement
When the image editor is used in Image or File fields (introduced in #36363), permission checks on the referenced dotAsset contentlet are broken across the stack. Multiple QA test cases uncovered four distinct failure modes:
1. No read permission → wrong HTTP status and generic error
When a user without read access tries to load a referenced dotAsset, GET /api/v1/content/<id> returns 404 instead of 403. The frontend receives no permission signal and displays a generic error:
"Something went wrong, please try again or contact our support team. Choose File"
No meaningful indication that the issue is a permission problem is shown to the user.
2. Read-only permission → edit button is not gated
The image editor edit button is shown and enabled regardless of the logged-in user's permission level on the referenced dotAsset. A contributor with only Read permission can open the editor and attempt to save.
3. Read-only permission → save failure is silently discarded
When a read-only user attempts to save edits, PUT /api/v1/workflow/actions/default/fire/PUBLISH?language=1 returns 403, but no error is shown to the user — changes are silently lost. The GET /api/v1/content/<id> response returns 200 with no read-only indicator, so the frontend has no signal to gate the edit button or warn the user before the save is attempted.
4. Edit/Publish permission → save still returns 403
Even when a user is explicitly granted Edit or Publish permission on the referenced dotAsset, the save operation returns 403 and the changes are not persisted. Additionally, the same user encounters an error when trying to open the dotAsset contentlet directly, even with all permissions set.
Steps to Reproduce
Read-only permission: edit button visible and enabled
Setup:
- Admin logs in; creates a dotAsset with a PNG image; notes the identifier.
- On the dotAsset Permissions tab: removes Edit permission from the Contributor role (keeps Read).
- Creates an "ImageEditorQA" contentlet referencing the restricted dotAsset.
- Assigns the Contributor role read-only host access.
Execution:
5. Non-admin user (Contributor role) logs in.
6. Opens the contentlet in Edit Content.
7. Observes the Image field area.
- Expected: Image preview is visible (Read permission granted); pencil icon is absent or disabled; no JavaScript errors.
- Actual: Edit button is shown and fully enabled.
No read permission: generic error instead of permission message
Setup:
- Admin creates a dotAsset with a PNG image; notes the identifier.
- On the dotAsset Permissions tab: removes all permissions from the Contributor role.
- Creates an "ImageEditorQA" contentlet referencing this dotAsset.
- On the contentlet Permissions tab: grants the Contributor role all permissions.
Execution:
5. Non-admin Contributor user logs in.
6. Opens the contentlet in Edit Content.
7. Observes the Image field area.
- Expected: No preview shown (no Read permission); no pencil icon; a message indicates the asset is inaccessible; no console errors.
- Actual: Generic error displayed: "Something went wrong, please try again or contact our support team. Choose File". Backend returns 404 instead of 403.
Read-only permission: save failure silently discarded
Setup:
- Admin creates a dotAsset with a PNG image; notes the identifier.
- On the dotAsset Permissions tab: grants the Contributor role Read only (no Edit/Publish).
- Creates an "ImageEditorQA" contentlet referencing the dotAsset.
- On the contentlet Permissions tab: grants the Contributor role all permissions.
Execution:
5. Non-admin Contributor user logs in.
6. Opens the contentlet in Edit Content.
7. Observes the Image field area; clicks the pencil icon, makes an edit, clicks Save/Apply.
- Expected: Preview visible (Read permission exists); pencil icon absent or disabled; asset unchanged; no console errors.
- Actual: Pencil icon is shown and enabled. After saving, PUT returns 403 but no error is shown — changes are silently discarded.
Edit/Publish permission: save still returns 403
Setup:
- Admin creates a dotAsset with a PNG image; notes the identifier.
- On the dotAsset Permissions tab: grants the Contributor role Edit and Read.
- Creates an "ImageEditorQA" contentlet referencing the dotAsset.
- On the contentlet Permissions tab: grants the Contributor role all permissions.
Execution:
5. Non-admin Contributor user logs in.
6. Opens the contentlet in Edit Content.
7. Clicks the pencil icon.
8. Makes a visible edit (e.g., rotate 90°).
9. Clicks Save/Apply.
- Expected: Save succeeds; preview reflects the edited image; dotAsset receives a new version (≥ 2 versions in history); no errors.
- Actual: PUT returns 403 and no changes are saved. Opening the dotAsset contentlet directly also fails with an error, even with all permissions granted.
Acceptance Criteria
- When a user has no read permission on the referenced dotAsset, the Image field displays a clear, permission-specific message — not a generic error
- When a user has read-only permission on the referenced dotAsset, the image editor edit button is not shown or is disabled
- When a save is blocked due to permission constraints, a visible error is surfaced to the user — changes are never silently discarded
- When a user has Edit or Publish permission on the referenced dotAsset, saving edited image content succeeds
- A user with all permissions on a dotAsset can open the dotAsset contentlet directly without errors
dotCMS Version
Latest from main branch (post #36363)
Severity
High - Major functionality broken
Links
- Related to #36363
- Test plan: 36363-36406-test-plan.md
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Image and File field flows and reproduce the cases in the linked 36363-36406 test plan. Inspect the GET /api/v1/content/ and PUT /api/v1/workflow/actions/default/fire/PUBLISH?language=1 responses, including direct dotAsset opening. Done means permission-specific feedback, gated editing, visible save errors, and successful saving for users with Edit or Publish permission.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, backend, frontend, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100