Determine if a user can access a resource in a snippet

That sounds like an ACL/permissions thing. Since you can't access it via getResources on another site, but you can on this one, I'd suggest examining the policies on the two and see if they aren't a little different at some point.

Are you logged into the Manager in the same browser? Even in a different window, MODX will consider you as having full admin permissions, but you'll be the (anonymous) user. That would explain most of what you're seeing.

You always have to test permission stuff in another browser where you're not logged in to the Manager.

No definitely not, I always test using a different browser [admin in chrome, test in FF etc]

I am baffled right now, been through the permissions, updated everything...

get resources CAN load a protected resource, but trying to visit that protected resource directly gives the 404 error.


Quote from: BobRay at Apr 02, 2013, 09:25 PM

Are you logged into the Manager in the same browser? Even in a different window, MODX will consider you as having full admin permissions, but you'll be the (anonymous) user. That would explain most of what you're seeing.

You always have to test permission stuff in another browser where you're not logged in to the Manager.

It may depend on the specific permissions involved. Load, list and view can affect that.

Let me re-suggest doing it with isMember(), which is much simpler and should be more reliable. It sounds like the users who should see the resource are already in a resource group, so you should be able to just check $modx->user->isMember() to see if the current user is a member of that group and forward them somewhere with $modx->sendRedirect() if not. You could also just check the username against '(anonymous)', which is by far the fastest way in terms of page load times.

There are approximately 12 or more different user groups a document can be available to any combination of those groups.


Quote from: BobRay at Apr 02, 2013, 10:19 PM

It may depend on the specific permissions involved. Load, list and view can affect that.

Let me re-suggest doing it with isMember(), which is much simpler and should be more reliable. It sounds like the users who should see the resource are already in a resource group, so you should be able to just check $modx->user->isMember() to see if the current user is a member of that group and forward them somewhere with $modx->sendRedirect() if not. You could also just check the username against '(anonymous)', which is by far the fastest way in terms of page load times.

Yes, that would be ugly, especially if users move from one group to another often.

With Resource Groups, I can think of reasons why a user would be denied access when they should have it, but I can't think of any way to explain users getting access they shouldn't have, especially the (anonymous) use, who shouldn't have any access to any protected resources.

Sorry I couldn't be more help.

Is it absolutely necessary that this run outside of MODX (i.e., not in a snippet)?

What doesn't make sense is the user gets access with the test snippet and getResources but is correctly denied access from the browser/url! That makes absolutely no sense whatsoever to me at all...

I rally wish it were possible to do this from the front end, but it's for an iphone app that delivers stripped down versions of the content to mobile devices. [what was that? 'responsive design' you say?? unfortunately it was someone else who sold them on the idea, I'm just responsible for the API to deliver content to their app. ]



Quote from: BobRay at Apr 02, 2013, 11:06 PM

Yes, that would be ugly, especially if users move from one group to another often.

With Resource Groups, I can think of reasons why a user would be denied access when they should have it, but I can't think of any way to explain users getting access they shouldn't have, especially the (anonymous) use, who shouldn't have any access to any protected resources.

Sorry I couldn't be more help.

Is it absolutely necessary that this run outside of MODX (i.e., not in a snippet)?

You may have "load" or "list" permission, which you need in order to check if the resource exists or is published or a lot of other checks that get made on resources, but if you can't "view" it then you'll get permission denied if you try to actually access it.

Well, it's something like that, anyway. My understanding of the ACLs and the various levels of the various permissions is still muddy.

Yes that was exactly it, the anonymous user needs load permissions on all the resource groups if you want to redirect them to an access denied page i.e. they can load the object in order to be able to tell if they can view it, but not actually view it. So, getResources, WayFinder etc were all working exactly as they should have.


Quote from: sottwell at Apr 03, 2013, 01:32 AM

You may have "load" or "list" permission, which you need in order to check if the resource exists or is published or a lot of other checks that get made on resources, but if you can't "view" it then you'll get permission denied if you try to actually access it.

Well, it's something like that, anyway. My understanding of the ACLs and the various levels of the various permissions is still muddy.

So kinda back to square 1, lots of things just don't work in API mode [and I have to use API mode] I thought I was on to something with $resource->findPolicy() - but that just returns an empty array. checkPolicy() always returns true, no matter who is logged in or what permissions they have...

Argh.

So I have to do this manually with some custom queries, can someone see if I have the gist right?

- get a list of resource groups the resource belongs to
- get a list of user groups the user is a member of
- check the resource group policy... this is a bit fuzzy.

any ideas what tables/joins have to be made?