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

Access ignored in List All Categories menu item #16757

Closed
kpmueller opened this issue Jun 19, 2017 · 29 comments
Closed

Access ignored in List All Categories menu item #16757

kpmueller opened this issue Jun 19, 2017 · 29 comments
Assignees

Comments

@kpmueller
Copy link

kpmueller commented Jun 19, 2017

Steps to reproduce the issue

I haven't been able to reproduce it yet on a fresh 3.7.2 install

System information (as much as possible)

PHP 5.6, Centos 6.x latest, Joomla 3.7.2

This Joomla has been migrated and updated since 1.6

Additional comments

I have a hierarchical category structure with access levels and groups for each level.

I create a List All Categories menu item which points to a parent level, with an appropriate access level (let's call it P). Inside are additional subcategories, (S1, S2, S3, etc.) with matching access levels. Inside the subcategories are articles, with have their category's subcategory access level.

Before 3.7, the menu item, when clicked, would show only subcategories which the user has access to. The user in 3.7 sees all subcategories, regardless if they have access. If they click on a subcategory link they don't have access to, they get a forbidden error (correctly).

So, the problem is clearly in the view of the parent category, showing children regardless of access levels the user is related to.

I have shown this in the SQL commands as follows:

https://gist.github.com/kpmueller/df426df43a3d1199bb97b0e6aa40861a

This is one of the subcategory queries. In the query, it is limiting itself by access level.

  LEFT JOIN j25_content_rating AS v 
  ON a.id = v.content_id

  WHERE a.access IN (1,1,4,5,6,41,89,218,285,287,313,329,367) 
  AND c.access IN (1,1,4,5,6,41,89,218,285,287,313,329,367) 
  AND c.published = 1 

https://gist.github.com/kpmueller/f87a9cd9047066ef20a2295e3fc6536a

This is the parent category query (from the List All Categories menu item). It has NO access level clause.

  LEFT JOIN `j25_content` AS i 
  ON i.`catid` = c.id 
  AND i.state = 1

  WHERE (c.extension='com_content' OR c.extension='system') 
  AND c.published = 1 
  AND s.id=176

The stack trace involved:

https://gist.github.com/kpmueller/06a7a59900416974556587a786b6c0d8

I believe this should be set, here: libraries/legacy/categories/categories.php:236

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

But, it seems there's not an _options['access'] setting in the model.

Earlier in the stack:

components/com_content/models/category.php:355

                        if (isset( $this->state->params))
                        {
                                $params = $this->state->params;
                                $options = array();
                                $options['countItems'] = $params->get('show_cat_num_articles', 1) || !$params->get('show_empty_categories_cat', 0);
                                $options['access']     = $params->get('check_access_rights', 1);
                        }
                        else
                        {
                                $options['countItems'] = 0;
                        }

There should be an options['access'] being set, based on a parameter, check_access_rights. For some reason, this is not happening.

This seems potentially to be related to an earlier PR, #11624

Unfortunately, I tried to reproduce this with a fresh joomla, and it seemed to be working properly, so I wonder if some kind of migrated data is involved. Nothing looked out of place. There must be somewhere further up where a parameter is not properly set, or lost?

If i can provide any more information, please let me know. I don't really know where to look next.

@kpmueller kpmueller changed the title Parent category in List All Categories menu item with Access not checked Access ignored in List All Categories menu item Jun 19, 2017
@ghost
Copy link

ghost commented Jun 20, 2017

@sanderpotjer can you please look at this issue?

@kpmueller kpmueller mentioned this issue Jun 26, 2017
@Webdongle
Copy link
Contributor

@kpmueller

I haven't been able to reproduce it yet on a fresh 3.7.2 install
Can you reproduce it by updating/migrating from 1.6 ?

@kpmueller
Copy link
Author

@Webdongle I haven't been able to reproduce it on a fresh 3.7.x either, so far. I don't have anything that old, just recent backups. It worked fine in 3.6.5 - went directly to the latest 3.7.x

Is there anything helpful I could do in debugging it?

@Webdongle
Copy link
Contributor

@kpmueller

Is there anything helpful I could do in debugging it?
If you have a backup of your 3.6.5 site
You could use Components >>> Joomla Update ... Upload & Update tab to update to install https://downloads.joomla.org/cms/joomla3/3-6-5/joomla_3-6-5-stable-update_package-zip?format=zip . This will make sure none of the core files are corrupt before attempting the update to 3.7.2 again

Can you
Install 3.6.5
Set up the Categories/Menu items in a similar way
Then update to 3.7.2 and see if the problem exists then ?

Without the ability to replicate the error I am at a loss as how to test it.

@ImagesbyMurray
Copy link

@Webdongle

I've just created a fresh install of Joomla 3.6.5 here
Logon as test, pwd:test to view the additional category

Upon your response, I'll go ahead and update to 3.7.3 ....

@Webdongle
Copy link
Contributor

When you can reproduce the issue then please post the method to reproduce it.

@ImagesbyMurray
Copy link

After the update to 3.7.3 - all child categories displayed in a category blog, or category list now show when viewing as public (child-category-1 has permission set to registered). Clicking on child-category-1 results in a 403 error

@ImagesbyMurray
Copy link

ImagesbyMurray commented Jul 6, 2017

@Webdongle To reproduce:

Fresh install 3.6.5
Create a Category, then Create Child categories - set permissions for one of these children to registered.
Add menu entry - Category Blog, using the newly created root category. Under Category Tab,
Subcategory Levels to ALL,
Empty Categories to SHOW
No Articles Message to SHOW

From front end - you will only see categories with public access, the category assigned to registered users does not show

Upgrade to 3.7.3
you can see result here

@kpmueller
Copy link
Author

Thanks for the assist in debugging this, @ImagesbyMurray !

I didn't yet try do it from an upgrade, and haven't had the chance to try anything with my own so far.

@Webdongle
Copy link
Contributor

Webdongle commented Jul 7, 2017

@ImagesbyMurray
Confirmed. Following your steps to reproduce
Before update
before update

After update the view/access level of the sub category is not honoured.
after update

Addendum
The same settings on 3.7.3 rc2 has the same result ... the access/view level of the sub category is not honoured.

@Webdongle
Copy link
Contributor

The change happened between 3.6.5 and 3.7.0
Install Joomla (github zip) with Testing sample data
Change the Access level of the sub Category 'Extensions' to 'Registered'
In Menus >>> All frontend views >>> 'Article Category Blog' menu item ... change the target category to 'Joomla!'
View All frontend views >>> 'Article Category Blog' from the front end
Scroll to the bottom and you will see the 'Extensions' category

Replace /com_content/models/category.php with the one from Joomla 3.6.5 and refresh the frontend view. The Access level is honoured and the the 'Extensions' category can no longer be seen.

Line 347 has $options['access'] = $params->get('check_access_rights', 1); added
Have tried changing the tab space to an ordinary space but no avail.

Line 190 has == replaced with === in the condition
Not sure if that is a deliberate change or a typo

@sanderpotjer
Could someone who is familiar with the code please look at this file and see where and why line 347 is not being honoured

@ImagesbyMurray
Copy link

@Webdongle Verified - I've replaced category.php on my test site, behavior is as expected, child category with registered access is now hidden from view

@kpmueller
Copy link
Author

Also confirmed on my end: I replaced the com_content/models/category.php with the 3.6.5 version, and things work correctly again.

@wojsmol
Copy link
Contributor

wojsmol commented Jul 8, 2017

@ImagesbyMurray @kpmueller Please revert only line 190 to state from Joomla! 3.6.5 and test if still works.
@Webdongle Changes in line 190 were introduced by @frankmayer as part of PR #12292.

@frankmayer
Copy link
Contributor

frankmayer commented Jul 8, 2017

I'll check my changes, but from a quick look, the changes in that file do not look suspicious to me. Will investigate further a bit later.

@frankmayer
Copy link
Contributor

frankmayer commented Jul 8, 2017

Could someone try remarking line 347
$options['access'] = $params->get('check_access_rights', 1);
in a (3.7.x versioned) com_content/models/category.php and seeing if it works then? (Sorry can't check it for the next few hours)

@frankmayer
Copy link
Contributor

frankmayer commented Jul 8, 2017

So I checked, and found out that when remarking/removing line 347 it does work.
I have not investigated further. This seems to be related to PR https://github.com/joomla/joomla-cms/pull/11624/files. @rdeutz pls check.

@Webdongle
Copy link
Contributor

@frankmayer
Have block commented and also tried with
$options['access'] = $params->get('check_access_rights', 1);
removed.
Both have resulted in the desired result of the category (with Access level 'Registered') not displaying.

Strange because I thought I had done that before with no avail. Must have edited the wrong copy before ?

@frankmayer
Copy link
Contributor

@Webdongle it could have been be a cache issue :) I always clean all caches (even if caching is off) when doing those kinds of tests.

Back to the issue: It would be interesting to see what happens when the changes of PR https://github.com/joomla/joomla-cms/pull/11624/files would be applied to a 3.6.5 version.
If the problem appears then, we know that it definitely has to do with that patch, and not with any other things that might have changed from 3.6.5 to 3.7.x
I don't have any 3.6.5 installations handy, so if anyone with a 3.6.5 installation could test that, it would bring us closer to identifying the problem for sure.

@Webdongle
Copy link
Contributor

Will try and use patchtester on a 3.6.5 to apply https://github.com/joomla/joomla-cms/pull/11624/files

@Webdongle
Copy link
Contributor

@frankmayer
Couldn't find the patch with patchtester so swapped the files manually
When both
components/com_content/models/category.php and libraries/legacy/view/category.php
From J3.7.3 are applied to J3.6.5
Then the category (with Access level 'Registered') displays ... Access level is ignored

When components/com_content/models/category.php or libraries/legacy/view/category.php
Then the category (with Access level 'Registered') does not display ... Expected behaviour

Hope that helps

@frankmayer
Copy link
Contributor

@Webdongle Thanks, that should confirm that the problem lies with that PR.

@kpmueller
Copy link
Author

In 3.8.2, without reverting to the old model category.php, I'm seeing the correct behavior seemingly now. Can anybody else confirm it's fixed now?

@ImagesbyMurray
Copy link

ImagesbyMurray commented Nov 19, 2017 via email

@kpmueller
Copy link
Author

OK, since everything seems fixed by #18408 , I'm going to close this issue!

@ImagesbyMurray
Copy link

ImagesbyMurray commented Jan 29, 2018 via email

@kpmueller
Copy link
Author

I'm not seeing a recurrence in my 3.8.3 install with the 3.8.3 category.php, as far as I can tell

Could it be something different, or something which wasn't tested in their fix?

@ImagesbyMurray
Copy link

ImagesbyMurray commented Jan 30, 2018 via email

@ImagesbyMurray
Copy link

Joomla 3.8.5 fixed the issue - see thread:
#19512

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants