Resource Groups / Protected Pages seems broken

Hi,

I'm trying to protect some web context pages so only specific logged in users can see them. I've followed every tutorial, and cleared cache/permissions probably 8 million times. I'm stumped, so I've deleted everything and started over with the https://docs.modx.com/revolution/2.x/administering-your-site/security/security-tutorials/making-member-only-pages tutorial, and I cannot get it to work. I'm starting to wonder if there's a bug in the permissions system, which would be catastrophic. This is ModX 2.5.7-pl, fresh install from yesterday.

The ultimate failure is that the protected pages *always* load for anonymous users, and WayFinder *always* lists them in the menu.

So, imagine a site with two pages:

- Public
- Private

• I've created a Resource Group "Protected", context:web, automatically give admin group access, do not give anonymous group access, do create parallel user group.
• I've added the Private page to the Protected Resource Group.
• I've created a user e.g. SpecialUser, who is a member of the Protected group.
• The Protected group has a Context Access of web, Member, Load/List/View policy, and a Resource Group Access of Protected, Member, Load/List/View policy.
• The (anonymous) group has a Context Access of web, Member, Load Only, and no Resource Group access.{/li]
  [li]The Administrator group has obviously the default web/mgr access, and Resource Group access of Protected, Member, Resource policy, Context:web.

Basically, nothing matters. The Private page will always load in a browser. Separate browser (IE instead of Chrome), history cleared, ModX cache cleared and logged out of all sessions every single time.

I've tried what feels like every combination of settings, and it's just not working. Even removing all access for the anonymous group, which one would think would block all access, will just has happily load protected pages and include them in the WayFinder menu.

After having spent two days basically doing the above steps again and again (and flushing caches), I'm about to give up and go to a simpler way like Bob's easy way of protecting pages. It just bothers me because (1) it should work, and (2) it's not great for layered permissions where multiple groups can get access to the same pages. This is an admin panel for 6 different types of users, and I'd have to bake probably 30 snippets to account for the combinations of group membership that has to be evaluated for any given page. And it's a pity to throw out what ought to work.

Anyway, any help is appreciated. And I hope I haven't found a bug, because that would be a whopper of a bug.

Thanks,

Per

Whenever I have had this problem it has been because I have not carried out both of these two functions from the Manager:

Manage / Flush your permissions
Manage / Logout all users

You have probably done both of those things, but as what you specifically mention is that you have

flushed caches, history cleared, ModX cache cleared and logged out of all sessions every single time.

I thought I had better be pedantic and double check exactly what you have done!

If you have done these two things and it is still not working I will look more closely at your post (when iI get home later) and see if I can see a problem elsewhere, as I have managed to get this working in 2.5.7.

Hi Andy,

Thanks for your response. I just got a major new data point: The session.auto_start PHP setting.

This "website" is an admin panel running separately from the main site, and I'm using www.phpgrid.com for the table editing. That has been a massive integration nightmare for many reasons, but the script also requires session.auto_start to be enabled. Bad setting for so many reasons. I lived with it because it's a 10 page site. I enable it only in the main directory, because the manager crashes with this enabled.

With that setting disabled, everything works out of the box. I don't know why, since ModX shouldn't be using sessions at all, and shouldn't care, but maybe I'm misunderstanding? I assumed ModX did its own database-based sessions and just stored a cookie.

This does not appear to be about some latent PHP session variable, because I've only been testing in a separate browser, I've been nuking settings all the time. It's also running as a Docker container, which has no memory, so I've been getting a clean slate over and over, also for PHP. It's the mere fact that the setting is enabled that's somehow tripping up ModX.

So I'll keep this wrapped in ModX and probably give up on this cursed phpgrid.com table script. At this point, I'm bleeding time, and I need something that works, even if it means buying a new expensive table script.

Best,

Per

Hi again,

Now that I know what to search for, it seems related to this issue: https://forums.modx.com/thread/96822/php-flag-session-auto-start-breaks-security

I'm crazy spooked by this. I've just spend an entire day confirming that seemingly innocuous server configuration can completely break ModX security. I don't know if this is a known issue that people are just living with, but this single PHP setting can bypass all access controls on the front end -- I've just spent an entire day proving it.

TO REPRODUCE:

1.) Create some protected pages that anonymous users should not be able to load.

2.) Enable session.auto_start in php.ini, or via "php_value session.auto_start 0" in the main web dir .htaccess.

3.) An anonymous user can access the protected pages.

This is a very simple "site" running on a Docker container as part of a large Amazon ECS deployment. Each container is exceptionally bare-bones, so it's not possible to blame any interactions. This system is as clean as it's possible to make a system. If I can inadvertently make this happen in this environment, that seems pretty bad if running ModX in an environment you have less control over, or that you don't understand as well.

Should we file a report?

And separately, why the heck does ModX care what I do with PHP sessions? I thought it didn't use PHP sessions.

Per

I just tested this in 2.4.7 and it's working normally for me. I think I did exactly what you described. When I log out and try to access the protected page, I get redirected to the home page. I can only access it when I'm logged in.

Double-check to make sure the Resource Group ACL entry exists for the Administrator group for that resource group with a context of web, and that the private page is actually a member of the resource group.

Make sure the resource isn't in any other resource groups.

Quote from: BobRay at Aug 21, 2017, 04:54 PM

I just tested this in 2.4.7 and it's working normally for me. I think I did exactly what you described. When I log out and try to access the protected page, I get redirected to the home page. I can only access it when I'm logged in.

Double-check to make sure the Resource Group ACL entry exists for the Administrator group for that resource group with a context of web, and that the private page is actually a member of the resource group.

Make sure the resource isn't in any other resource groups.

Hi Bob,

Please enable session.auto_start as described above. The moment I disabled it, the current setup started working. When auto_start is enabled, anonymous users can access protected pages.

Per

H<

Just double-checked, and I can say with absolute certainty that session.auto_start is causing it.

In the .htaccess in the document root, the following settings produce these results:

* php_value session.auto_start 0 -- redirects to login page.

* php_value session.auto_start 1 -- displays protected page.

Best,

Per

I think you should definitely file that as an issue here.