Tested all with a third site at different provider.
Everything as expected, test page is protected for users not logged in.
Is there a way to “clean” the system so that it “forgets” all prior activities with resource groups, user groups, users and permissions? Can’t find a reason why the first system doesn’t work as expected.
No.
There is just the data in the various database tables (concerning users, user groups and resource groups) that then gets written to the MODX cache folder to speed up requests.
Ok, then there must be another reason for this strange behaviour. But how to find a solution? I’m confused. Further testing …
Ha, now I get a 404 error when I’m not logged in. (And I don’t know why …)
Einstein said: “Insanity is doing the same thing over and over again and expecting different results.” Seems it worked in this case anyway. Will keep testing it over the next few days.
Cleared the cache multiple times and created groups and users also multiple times. Don’t know why it works now.
@halftrainedharry Thanks for your help!
Maybe I’m misunderstanding what you did, but did you connect the private USER group to the to the resource group with the context ‘web’ with a resource group access ACL entry?
The key to protection is to connect the private user group to the private resource group. Nothing you do with just the resource group will protect the resources.
You could also try using a role/authority level other than member, since the (anonymous) users are also technically members. I’ve never tried to protect anything using an authority of member, so TBH, I’m not sure what that does.
As a last resort, you can put a snippet tag at the top of the pages (or in their template): [[!Protect]] with this code in the Protect snippet:
<?php
if (! modx->user->isMember('name of private group') {
$modx->sendErrorPage();
}
Thanks, but yes, I connected the private user group to the resource group with the web context with the resource group access ACL entry.
However now it works correct. I created a second private page for a second user group and it is also protected.
I need to check some other setting, maybe I found the reason for my problems. Could be an older system setting I deleted now. Will test it again but not today and write here a response.
The snippet looks good and helpful, will test it.
Now I found the reason for my problem.
I had defined an old session setting for a sessionless frontend (at the beginning of the GDPR/german: DSGVO regulations) like described here: session_enabled - System Settings | MODX Documentation
I deleted it and it works stable as expected.
That would do it. 