Answered getResources + Resource Group ACL = Resource Group Perms Breaking

Environment:

MODX 2.2.8 standard
getResources 1.6.0-pl


In a nutshell, getResources is displaying resources in its output it shouldn't be displaying, based on assigned Resource Group permissions.

I have a group of resources devised for internal use only, that I want to display in a navigation area if the user is logged in and meets the appropriate access criteria. If the user is logged in, and is assigned to the correct user group ACL, then the resource links should appear. If the user is not logged in (i.e., "anonymous") the links should not appear.

I've done this exact same type of content output in the past with Wayfinder, and it worked perfectly.

However, I recently changed the content chunk for this navigation bar to use getResources instead of Wayfinder, and now "anonymous" users are seeing the links for the "Internal Only" resources, when before Wayfinder was correctly hiding them.

I have the resource group in question set up with the "Load Only" permission for anonymous users for the standard "web" context. If I'm understanding correctly, getResources should NOT display links to anonymous users for these resources. If I set the permission in the resource group to "Load and List," THEN getResources should display them, but NOT for "Load Only."

Is this correct? Because as far as I can tell, getResources is not correctly respecting the resource group assignment and permissions.

Again, when I was using Wayfinder to build this block of content, the links were correctly hidden until the user logged in. I generally prefer to use getResources, since its basic structural syntax and placeholder scheme is more intuitive for me, but I can easily change the content block back to Wayfinder, so that's not a big deal. It's just very, very odd to me that Wayfinder is doing this correctly, and getResources isn't.

Any ideas on why getResources is failing in this regard, when Wayfinder seems to work?

UPDATE: Confirmed that Wayfinder is working correctly, and getResources is not. As soon as I changed the content block to use the appropriate Wayfinder snippet call and TPLs, the "internal only" resources immediately became hidden like they were supposed to for anonymous users. [ed. note: felonius last edited this post 12 years, 8 months ago.]

Do you have a &where property or a &resources property in the tag? I think the permissions may be ignored if those are present. I could be wrong.

Here's my snippet call:



I've heard that there can be some strange behavior when you set the getResources &parents parameter to 0, but it doesn't seem to be affecting the output of the content; it's just ignoring the resource group assignment.

The TPLs are very straightforward; the wrapper has the [[ +output ]] nested in a div, and the item tpl is a div with a link to the resource id

.

Everything else is CSS. I am calling a conditional modx.user.id statement in the wrapper to change the login / logout link, but that shouldn't affect the getResources call. [ed. note: felonius last edited this post 12 years, 8 months ago.]

You might want to try pdoTools and its pdoResources snippet. It's more efficient, and may not have the same problem.

Okay, I went a little deeper into the "Load Only" permission for the Resource Group.

It turns out, the "Load Only" policy is somehow adding the following to the Resource Group:

list, load, remove, save, view

If I change the policy to "Load, List, View" it updates to show: load, list, view

If I save the policy at that point, it saves correctly.

HERE'S WHERE IT GETS WEIRD: If I go back, and then change the policy back to "Load Only," when the permissions first appear on the pop-up, it shows "Load" as the only permission that will be allowed.

HOWEVER, after I save the policy, and go back and edit it again, the system has added list, load, remove, save, view BACK to the saved policy.

In other words, somehow, the resource group is being given permissions that aren't even listed in the ACL itself.

I wanted to try and see if it was a problem with the permissions themselves. So I just went and created a custom access policy template with "load" as the ONLY permission in the template, then created a custom policy based on that template.

I removed the standard "Load Only" policy from the resource group for anonymous users, and replaced it with the new custom policy.

I then flushed permissions and cleared the cache. I then verified that the new access policy had only saved the "load" permission to the resource group, which it had.

No change in getResources.

I then went and changed the actual anonymous group policy for the web context directly. I thought if "Load Only" was adding "list, load, remove, save, view" to the context itself, that it may be overriding the resource group policy. So I removed the standard "Load Only" policy, and replaced it with my custom policy. Flushed permissions, cleared cache.

Still no change in getResources.

I thought maybe the &parent parameter as `0` might be causing a problem, so I changed &parent to a child resource that should have been added to the resource group, as well as its children. Cleared the cache.

Still no change.

I then removed my custom "load only" policy from the resource group.

And, voila! getResources removed the items.

So, apparently, Wayfinder does something differently in the way it processes or queries for resources that getResources does not. Wayfinder is apparently checking against the "view" permission, and disallowing the link to appear if the user does not have a "view" permission for the returned resource. Whereas it appears getResources is basing its check on "load" and "list."

This sounds like a possible enhancement / new parameter for getResources --- include a parameter for &checkResourceView=1 or 0. "TRUE" changes the behavior to act like Wayfinder, where the returned content is filtered out if the user does not have a "view" permission. "FALSE" acts like it does now. [ed. note: felonius last edited this post 12 years, 8 months ago.]

Thanks for checking into that Bob, that's very, very helpful.

So, it sounds like getResources will always display links to any content specified in the query parameters and filters, regardless of resource group assignment, if the resource group in question has the "load" permission as part of its ACL.

To hide resources in a resource group from getResources (that's only slightly confusing LOL), you have to take away the load / list / view permissions away from the resource group policy assignment.

Otherwise, use Wayfinder, which checks against the "list" permission. So if your resource group limits anonymous access to "Load Only," it won't appear.

you can of course have a snippet, which does return a list with negative ids of private resources, where the current user doesn't have permission to view them.

and put that list to the getResources-call: