Restricting front-end access to (anonymous)

14 Posts

handyface Reply #11, 11 years, 8 months ago

Thanks, I added the tag. I found out the issue has nothing to do with the contexts. I installed a fresh MODX on my WAMP and found out that it's not even working with the web context. Or I might be missing something... I opened https://github.com/modxcms/revolution/issues/12270 with steps on how I reproduce this issue. It's weird that it looks like I am the only one facing this problem. I'd highly appreciate if someone else would be willing to try and reproduce this problem just so I know it's not just my stupidity.

24,544 Posts

BobRay Reply #12, 11 years, 8 months ago

This code in the modAccessibleObject class file is definitely worth a look. This is in the checkPolicy() method (called by hasPermission() ):

if ($criteria && $this->xpdo instanceof modX && $this->xpdo->getSessionState() == modX::SESSION_STATE_INITIALIZED) {
    /* ... */
}
return true;

If that "if" condition isn't met, the user has permission for everything.

It's worth noting that if PHP is reporting the wrong thing for cli mode tests, it would explain your problem, because in CLI mode, the session_state is set to UNAVAILABLE and there are no permission restrictions.

Try this code in a MODX snippet in the front end:

echo 'SAPI NAME: ' . php_sapi_name();
echo '<br />XPDO_CLI_MODE ' . XPDO_CLI_MODE;

[ed. note: BobRay last edited this post 11 years, 8 months ago.]

Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting

14 Posts

handyface Reply #13, 11 years, 8 months ago

Hey Bob,

I just tried your snippet code (only I replaced the colon ':' with a dot '.' because it was invalid code) and the output was as follows:

SAPI NAME: cgi-fcgi
XPDO_CLI_MODE

I tried outputting the haspermission function in a snippet to check whether the permissions are working. They are. I can confirm that the front-end gets displayed even though the 'load' and 'view' persmissions are not present. So I wrote this little snippet as a little hacky solution and placed it on every template.

if (!$modx->hasPermission('load')) {
$modx->sendUnauthorizedPage();
}

However I would like to fix this issue so that I know modX (and the ACL's) are working as intended and my site is secure without hacky solutions. If you know what I mean.

24,544 Posts

BobRay Reply #14, 11 years, 8 months ago

Those results mean that it's not what I thought it was. At this point, I don't know what could cause that other than a corrupted MODX file, though that usually causes more catastrophic problems. It's fairly common if you transfer the MODX files individually with FTP. Also, if you upgraded, it's possible that one or more files didn't get overwritten.

At some point, I'd be tempted to do a fresh install in another directory with a new DB and see if the problem persists. If that solves it, you could move individual tables across, checking as you go, and when it's all working, just rename the directories.

Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting

14 Posts

handyface Reply #15, 11 years, 8 months ago

I tried a fresh install on both a local (wamp) and a remote (a proper shared webhosting) and I still get the issue. When I remove the default Load permission for the anonymous group on the web context, the homepage is still visible. I'm surprised no one else has this issue.

☆ A M B ☆
24,524 Posts

sottwell Reply #16, 11 years, 8 months ago

What is your error_page set to in System Settings? If a user doesn't have load permissions they'll get the Not Found error page.

Studying MODX in the desert - http://sottwell.com
Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
Join the Slack Community - http://modx.org

14 Posts

handyface Reply #17, 11 years, 8 months ago

The error pages are set to a different page. I can see in the network panel of my chrome inspector that the page status is 200.

☆ A M B ☆
24,524 Posts

sottwell Reply #18, 11 years, 8 months ago

Actually, checking this out, removing the web context access from the (anonymous) group doesn't prevent anonymous users from accessing any non-secured pages. I don't think it works that way. I'm pretty sure that pages - at least "web" context pages - are available to everybody unless they are put in resource groups that are connected to user groups.

Studying MODX in the desert - http://sottwell.com
Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
Join the Slack Community - http://modx.org

14 Posts

handyface Reply #19, 11 years, 8 months ago

Are you sure about this? So even though the user group has no 'load' permission, they are supposed to be able to view the content? That seems really strange to me.

☆ A M B ☆
24,524 Posts

sottwell Reply #20, 11 years, 8 months ago

I don't think that the 'web' context or the (anonymous) group behaves like other contexts and groups.

Studying MODX in the desert - http://sottwell.com
Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
Join the Slack Community - http://modx.org