?
avatar infograf768
infograf768
5 Sep 2015

While making the PR #7824, I found that I could not solve the issue when a category is concerned.
Test:
Create a menu item displaying a category. Set its access to Public.
Set the category access to Registered.

When displaying the menu item in frontend (not logged in) one will get an error page with
404 Category not found

We should instead get a You are not authorised to view this resource.

I traced this to:
https://github.com/joomla/joomla-cms/blob/staging/libraries/legacy/view/category.php#L120-L136

Basically, it looks like a category is considered false when access is not authorised.

avatar infograf768 infograf768 - open - 5 Sep 2015
avatar zero-24 zero-24 - change - 5 Sep 2015
Category Libraries
avatar zero-24 zero-24 - change - 5 Sep 2015
Labels Added: ?
avatar Bakual
Bakual - comment - 7 Sep 2015

The category is loaded using

$categories = JCategories::getInstance('Content', $options);
$this->_item = $categories->get($this->getState('category.id', 'root'));

See https://github.com/joomla/joomla-cms/blob/staging/components/com_content/models/category.php#L356-L357

which is running already an access check:

if ($this->_options['access'])
{
    $query->where('c.access IN (' . implode(',', $user->getAuthorisedViewLevels()) . ')');
}

See https://github.com/joomla/joomla-cms/blob/staging/libraries/legacy/categories/categories.php#L237-L240

as you see it is an option which can be set. It defaults to true (set in the constructor).

So you would have to disable the access check in the model.if you want to do the check it in the view. Adding that line $options['access'] = false; before the code in the model should do it. But I have no clue what side effects that could produce.

avatar infograf768
infograf768 - comment - 7 Sep 2015

did what you suggest (I think) but to no effect. $category is still null

avatar Bakual
Bakual - comment - 7 Sep 2015
$options['access'] = false;
$categories = JCategories::getInstance('Content', $options);
$this->_item = $categories->get($this->getState('category.id', 'root'));

in https://github.com/joomla/joomla-cms/blob/staging/components/com_content/models/category.php#L356-L357 should work. At least it did for me when testing with com_content.
Other extensions may need similar code.

avatar infograf768
infograf768 - comment - 8 Sep 2015

Indeed, this works, but as I tested further, I discovered another bug (with or without this code)
Make a Home menu item displaying a featured article view.
The featured articles all belong to a registered category.
The articles will display...

Note: with the new code, there are indeed consequences: displaying public parent category will also display link to registered category. (In the case above it redirected to home page)

avatar Bakual
Bakual - comment - 8 Sep 2015

Make a Home menu item displaying a featured article view.
The featured articles all belong to a registered category.
The articles will display...

Isn't that quite a stupid setup to begin with? If the home menu item isn't supposed to show public articles/categories, what should it show to guests then? Just an error message?

avatar infograf768
infograf768 - comment - 8 Sep 2015

Ok, take it like this then:
A home featured menu item is displaying many articles from public/published categories, but will also display the ones from the registered category.

The question is simply: should the items contained in a category —to which one has no access— be displayed or not on a joomla site?

avatar joomdonation
joomdonation - comment - 9 Sep 2015

A home featured menu item is displaying many articles from public/published categories, but will also display the ones from the registered category.
The question is simply: should the items contained in a category —to which one has no access— be displayed or not on a joomla site?

=> It seems it is controlled by the "Show Unauthorised Links" parameter of the menu item (in Options tab). If you set it to No (I think it is default behavior), these articles won't be showed.

avatar rdeutz
rdeutz - comment - 17 Aug 2016

closing because we have a PR #11624

avatar rdeutz rdeutz - change - 17 Aug 2016
Status New Closed
Closed_Date 0000-00-00 00:00:00 2016-08-17 20:57:34
Closed_By rdeutz
avatar rdeutz rdeutz - close - 17 Aug 2016

Add a Comment

Login with GitHub to post a comment