UVE: 🐛 Prevent Read-Only Token Access to Working Content

[fmontes]

Problem Statement

Read-only API tokens are incorrectly allowed to access the working content of pages with future date set in the Page API, violating access control policies and potentially exposing unpublished content prematurely.

Objectives

• Correctly enforce access controls based on user permissions.
• Ensure that only live content is accessible by read-only tokens.

User Story

As an IT Security staff member, I want to ensure that read-only tokens can only access live content and not any working versions, so we can maintain content integrity and adhere to strict access policies.

Steps to reproduce

1. Create a page with content in the future
2. Request that page with the publishDate in the future to see the content and a read only token
3. The content is returning and it should return a 401

Acceptance Criteria

Preview Give feedback

1. The API should return 401 when accessed by read-only tokens and pass publishDate
2. Access violation attempts are logged with appropriate error messages.
3. Documentation is updated to reflect the corrected access permissions.

External Links

[Placeholder for external links to Slack conversations, support tickets, Figma designs, etc.]

Assumptions & Initiation Needs

• Assumes that the API currently handles different types of tokens with varying access levels.

Quality Assurance Notes & Workarounds

[Placeholder for QA notes]

Technical Details

The API needs adjustments particularly in how permissions are verified for future-dated content requests.

Potential Challenges

• Ensuring that the fix does not interfere with access rights for other user roles.

Impact on Existing Features

Ensure that permission checks do not negatively impact legitimate user accesses or API response times.

[github-actions]

PRs:

• fix(PageAPI) Permissions Accessing Working Content  #31068
• fix(TimeMachine) Permissionable shortLivedKey was bad + Skip Velocity cache when time-machine is set #31222

[fabrizzio-dotCMS]

I have been testing different users with “read-only” tokens, and the 401 response is not necessarily expected.
For example:
Take Chris Publisher: remove the back-end role, apply the changes, and ensure they cascade. Now, create a token and access a page. CP can still access the page’s content.

Next, take a user created from scratch, assign only the back-end role, and grant “view” permissions for the site of interest. If you use the token immediately, you’ll get a 401. However, if you apply the changes in cascade, the token will now allow access to pages, and permissions should apply for filtering.

That said, I encountered a bug when filtering content in the “working” state. The issue arises because the construction of one of the objects used for filtering is taking the system user instead of the logged-in user.

[fabrizzio-dotCMS]

These fixes were merged as part of the branch #31072 therefore it can be tested and no additional merge is required

[fabrizzio-dotCMS]

This is what I have been using for testing:

curl -X GET 'http://localhost:8080/api/v1/page/render/ftm-test-page8218?language_id=1&mode=LIVE&publishDate=2025-01-31T10:00:00.000Z' \
-v -H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhcGk0NWUwZGU2ZC01MDQ2LTQ2MWMtYTZjZC00N2U1ZDIwZDFlZWUiLCJ4bW9kIjoxNzM2ODE4NDI1MDAwLCJuYmYiOjE3MzY4MTg0MjUsImlzcyI6IjU4ZmI5YzQzMjYiLCJsYWJlbCI6ImxvbCIsImV4cCI6MTgzMTQzODgwMCwiaWF0IjoxNzM2ODE4NDI1LCJqdGkiOiI3ODY3ZmM3MS1hMGM5LTQ4NmItOGUyZi0yYzBhNjMxNzU3MWIifQ.XsSCuTQMqnK5HaEkHpVuzad4RajgXyp-9CHSmCIXUo0' 

The bearer token blongs to a user that was created then assigned a front-end role only
This gets me consistently a 403 everytime I attempt to access the page with working content

[KevinDavilaDotCMS]

After conducting several test cases, it was determined that the issue is related to a caching problem, as the order in which the tests are performed directly impacts the results.

To address this, a script was created to facilitate testing more cases in less time (attached). The following steps were followed:

1. Create a new page.
2. Add a ContentType that includes publishDate and expiredDate. [Tutorial]
3. Add a new contentlet of this ContentType without assigning it a future publish date (this means the contentlet has a LIVE version).
4. Edit the contentlet to add a future version and publish it.

Various scenarios were tested by requesting the page in EDIT_MODE, LIVE, and PREVIEW.

Findings

The following issue, which is very likely related to the ticket, was discovered:

Using a Front-End token:

Initial Request in LIVE mode without the publishDate query parameter:

When requesting the page, the pageAPI responds correctly, displaying only the LIVE contentlets.
Subsequent Request with the publishDate query parameter: The pageAPI returns the page with future contentlets included. (This should NOT happen.)

Then Clearing Cache,

After clearing the cache, the behavior changes:

First Request in LIVE mode WITH the publishDate query parameter:
The pageAPI returns a "403 - You don’t have permission" error. (This is correct.)
Subsequent Request without the publishDate query parameter: The pageAPI still responds with a "403 - You don’t have permission" error, even though the query parameter was removed

It appears that when the page is requested, it gets "stored" in cache, and subsequent requests retrieve the cached version instead of rebuilding the page. This behavior seems to cause the issue when the publishDate query parameter is used.

Additionally, this caching behavior seems to be why the unit test does not fail, as it’s likely that the cache does not affect the test environment.

tests-cases.zip

[rjvelazco]

Blocker Found:

ftm.mp4

[jdcmsd]

Seems the FTM issue is not quite solved, yet. I fired up 25.02.07, and was initially seeing the same behavior that I had reported in my video from the Scout channel: https://dotcms.slack.com/archives/CQNF9PCFQ/p1738680630969759?thread_ts=1738610618.649869&cid=CQNF9PCFQ

However, after a browser-cache-clearing hard refresh, it seems to have gone in the other direction: now the working version doesn't show up under any of the modes, including Live mode after the publishing date.

Screen.Recording.2025-02-07.at.3.51.42.PM.mov

[fabrizzio-dotCMS]

it looks to me like the issue is Front-end

TM-cache.mov

[zJaaal]

I'll be investigating this issue that @fabrizzio-dotCMS is reporting to discard or confirm frontend issues.

[zJaaal]

it looks to me like the issue is Front-end

TM-cache.mov

This is happening due to use of the identifier to fetch the image from the Image API in this file application/containers/banner/banner.vtl. When you change the code to fetch the image using the inode it works accordingly

Looks like the Image API is not taking in count the context of the Page it is being rendered at the moment. I recommend to dig into this in the backend side.

[nollymar]

The last issue found by @zJaaal will be fixed on here