Can't get load/lists perms to work on a non-web context

Is there a trick to using the unauthorized page on non-web contexts? On the 'web' context, I've used the following model successfully to display links to restricted pages, and display the "unauthorized" page when the anonymous user tries to view them:

• Grant "load/list" permissions to the anonymous user for the restricted Resource Group
• Anonymous user can see links to those resources, and sees the Unauthorized page (as defined by unauthorized_page when he/she clicks on them.

Is there something different I need to be doing on an alternative context? I've given the anonymous user load/list perms on the RG *for the new context*, but the resource in question isn't showing up in my nav menus for the anonymous user. Also, I have a plugin that runs on OnPageUnauthorized, and it isn't firing properly for requests from the new context - it is supposed to write a message to the error log that it is running, and I'm not seeing it for requests from this context.

What I do see for these pages, instead of seeing the unauthorized page, is "503 Error Page not found" in the content, and a 404 status.

Did you specify an error_page context setting for this particular context and pointed it to the proper resource?

Quote from: benmarte at Jun 28, 2013, 12:24 PM

Did you specify an error_page context setting for this particular context and pointed it to the proper resource?

I hadn't done that when I posted this, but I have done so since. The error_page directive does seem to be working okay - it routes to the correct error resource. But the issue is that these particular resources need to trigger a sendUnauthorizedPage event rather than a sendErrorPage event. The permissions should be load/list (but not view) to trigger the unauthorized event, but that is not working for some reason.

Try adding a unauthorized_page context setting and see if that works.

Quote from: benmarte at Jun 28, 2013, 12:36 PM

Try adding a unauthorized_page context setting and see if that works.

I do have that in place as a context setting, and it isn't working (had it in place before I had error_page even).

Currently I'm debugging/troubleshooting in modrequest.class.php, trying to figure out why sendErrorPage is being invoked.

If users (including the anonymous user) don't have "load" permissions for the context, you will only get the not-found page, since the page isn't even loaded and so never checks for permissions.

Quote from: sottwell at Jun 28, 2013, 12:42 PM

If users (including the anonymous user) don't have "load" permissions for the context, you will only get the not-found page, since the page isn't even loaded and so never checks for permissions.

The anonymous use does have load permissions for this resource group on this context. I understand how this is necessary to distinguish between "not found" and "unauthorized" and have used the concept quite successfully in the past. It just isn't behaving as normal on this context.

I think for now I'm just going to prompt users to log in from the main page (the unauthorized page just prompts them to log in.) That way they'll be in the more privileged group sooner rather than later, and be authorized to see the restricted pages.

I'd still like to figure this out, though, for my own understanding.

Did you also give the anonymous users load permission in a *Context* Access ACL entry for the other Context? Without that, the one in the Resource Group Access ACL entry will have no effect.

See the Anonymous group's Context Access ACL entry for the 'web' context as an example.

Quote from: BobRay at Jun 28, 2013, 11:14 PM

Did you also give the anonymous users load permission in a *Context* Access ACL entry for the other Context? Without that, the one in the Resource Group Access ACL entry will have no effect.

See the Anonymous group's Context Access ACL entry for the 'web' context as an example.

It does have a context access acl.

Like many things related to MODX permissions, this started working exactly as I wanted it to about 3 hours later, when I left it and came back. I'm not sure what that is all about, but it seems to happen fairly often. I was definitely clearing cache while testing, but there must be something else going on...

You also need to flush permissions and flush all sessions on the Security menu, but maybe some stuff is stuck in the browser cache.