Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[4.4] Align the access checks for the unpublished articles in frontend category #42694

Open
wants to merge 2 commits into
base: 4.4-dev
Choose a base branch
from

Conversation

ManuelHu
Copy link
Contributor

This aligns the access checks for the published state and the publish_up/down checks to both use the given filter.published.

Pull Request for Issue #42452.

Summary of Changes

The main CategoryModel model has the right access checks in

if ((!$user->authorise('core.edit.state', $asset)) && (!$user->authorise('core.edit', $asset))) {
// Limit to published for people who can't edit or edit.state.
$this->setState('filter.published', 1);
} else {
$this->setState('filter.published', [0, 1]);
}

Here, the access to the single category in question is checked the right way (i.e. by including the category id in the asset name).

But the category model does not filter the articles itself. For this, it calls into ArticlesModel:

if ($this->_articles === null && $category = $this->getCategory()) {
$model = $this->bootComponent('com_content')->getMVCFactory()
->createModel('Articles', 'Site', ['ignore_request' => true]);
$model->setState('params', Factory::getApplication()->getParams());
$model->setState('filter.category_id', $category->id);
$model->setState('filter.published', $this->getState('filter.published'));

and passes on the filter.published state.

But in ArticlesModel::getItems(), the access check is repeated with a generic asset tag (i.e. com_content w/o any category information), but only for the publish_up/down case. In the simple published case, no additional access check is performed, and just the value of filter.published is used.

// Filter by start and end dates.
if ((!$user->authorise('core.edit.state', 'com_content')) && (!$user->authorise('core.edit', 'com_content'))) {
$query->where(
[
'(' . $db->quoteName('a.publish_up') . ' IS NULL OR ' . $db->quoteName('a.publish_up') . ' <= :publishUp)',


This patch essentially aligns the access checks for the published state and the publish_up/down checks to both use the given filter.published.

Testing Instructions

  1. Create a content category
  2. create articles in it
    • at least one with published state
    • one with published state and with publish_up in the future
    • and one set to be hidden
  3. Create a user group and grant access to edit and edit-state for this category only
  4. create a category list menu item in the frontend menu
  5. log into the frontend with a user that is part of the group created in step 3

Actual result BEFORE applying this Pull Request

  • the user can only see two of the articles: the published one, and the hidden one.
  • The article with publish_up in the future is not visible

Expected result AFTER applying this Pull Request

  • the logged-in user can see all three articles
  • Note that this only changes the content of the list. The user always had the permission to view and edit the article (i.e. by "guessing" its URL), it was just not listed.

Link to documentations

Please select:

  • Documentation link for docs.joomla.org:

  • No documentation changes for docs.joomla.org needed

  • Pull Request link for manual.joomla.org:

  • No documentation changes for manual.joomla.org needed

…gory

This aligns the access checks for the `published` state and the
`publish_up/down` checks to both use the given `filter.published`.
Co-authored-by: Quy <quy@nomonkeybiz.com>
@HLeithner HLeithner added the bug label Apr 24, 2024
@HLeithner HLeithner changed the title Align the access checks for the unpublished articles in frontend category [4.4] Align the access checks for the unpublished articles in frontend category Apr 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants