Why?

@brianteeman The code uses application secret stored in configuration.php for secure token creation and validation. However, that secret is not really secret. We use that secret to generate other data which is public viewable such as asset version, form token..., so in theory, that secret could be leaked. In case it is leaked, someone will have access to unauthenticated articles.

According to AI, it will take billion years at the moment to leak our 16 characters secret, so in practical, it's very unlikely this will happen but maintainers decided it could be potential security issue and decided to revert the PR.

yes i know that but whyv revert instead of fix - tha's the question

Maintainers decided to revert PR 48030 for security reasons - this PR does this cleanly.

Thank you!

@joomdonation, @brianteeman, @MacJoom, @drmenzelit If we won't fix the issue in the reverted PR, then why don't we go with the other one? It fixes the same issue but in another way other than the configuration.php secret token, we can also improve it. This is in case we won't fix the problem in the reverted PR.

@CSGoat0 we didn't got a fix before Beta 2 and since it was a security issue we had no other chance than revert it. 6.2 is now in feature freeze. This new feature (as fixed PR from Tuan or with your approach) has to go into 6.3.

@drmenzelit, i can switch the branch to 6.3 but need to know which approach we will take?

Will we fix the issue in the reverted PR or use the other one?

Discussed this in Maintainers (2.9.2026): We might think about a way to bypass ACL in a structured and secure way. So we are for a concept first and then follow with an implementation.

I made a preview unpublished article plugin a year ago. While it probably doesn't meet all your criteria for integrating into core, a few things worth considering:

• Decouple tokens from $secret via dedicated storage: Stateless tokens derived from the global $secret risk site-wide exposure if that secret leaks. Generating cryptographically secure random tokens (random_bytes(32)) persisted with an article_id and timestamp keeps previews single-article scoped, time-limited, and completely isolated from site secrets.
• Automate cleanup via Scheduled Tasks: To prevent table bloat without manual overhead, pair the preview token table with a native Joomla Scheduled Task routine (TaskPluginTrait) that automatically purges expired tokens based on a configurable TTL (e.g., 24h, 3d, 7d).
• Keep the bypass strictly in memory at the model query level: Front-end rendering for unpublished articles should never mutate database records. When a valid token is verified, instruct ArticleModel::getListQuery() / getItem() to selectively omit the a.state = 1 and a.publish_up SQL constraints in memory for that specific article ID only.