-
Notifications
You must be signed in to change notification settings - Fork 480
Description
Problem Statement
Content Drive pagination is particularly complex because it relies on multiple data sources and is built on top of the BrowserAPI. When this functionality was originally implemented, only the minimum required changes were introduced to allow both features to coexist.
For example, when applying permission filtering, the following call was intentionally left unchanged:
permissionAPI.filterCollection( contentlets, PERMISSION_READ, true, browserQuery.user );
At the time, it was assumed that all permission filtering logic was handled entirely on the server side.
However, this assumption was incorrect. As part of the original Site Browser implementation, a portion of the permission filtering is actually performed on the frontend, specifically in:
src/main/webapp/html/portlet/ext/browser/view_browser_js_inc.jsp
Within the functions:
• initializeTree
• selectFolderContentCallBack
These functions are invoked through:
BrowserAjax.getTree and BrowserAjax.openFolderContent, respectively.
Because the server-side permission filtering line was left untouched under the assumption that all filtering occurred on the backend, this gap in responsibility went unnoticed. As a result, the bug was unintentionally introduced.
The following screenshot shows that the restricted item still makes it to the frontend, but it doesn't get rendered in the folder content.
Steps to Reproduce
Screen.Recording.2026-01-19.at.9.15.23.AM.mov
Acceptance Criteria
No info should be leaked
dotCMS Version
main
Severity
Medium - Some functionality impacted
Links
https://dotcms.slack.com/archives/C08MTB0RH6D/p1768771946893399
Metadata
Metadata
Assignees
Labels
Type
Projects
Status