Revolution Permissions

First, after changing any permissions, make sure you Flush Sessions. User policies are cached in session and are not updated automatically when you change the ACLs.

Second, 404 is the correct response if anonymous users do not have the load permission on a Resource Group protecting a Resource. If a user accessing a Resource in a MODx front-end Context does not have permission to load it, it’s as if the page does not exist at all and the error_page is returned. If they have the load permission on it but do not have permission to view it, then it will respond with a 401 using the unauthorized_page.

Quote from: OpenGeek at Jan 22, 2010, 10:16 AM

First, after changing any permissions, make sure you Flush Sessions. User policies are cached in session and are not updated automatically when you change the ACLs.

Second, 404 is the correct response if anonymous users do not have the load permission on a Resource Group protecting a Resource. If a user accessing a Resource in a MODx front-end Context does not have permission to load it, it’s as if the page does not exist at all and the error_page is returned. If they have the load permission on it but do not have permission to view it, then it will respond with a 401 using the unauthorized_page.

I did flush permissions.

Now, it’s not an anymous user who try to access the page, it’s the logged user1 who does not belong to group2 resources.
And it has the load attribute.
Should i put in group1 the pages of group2 and give a higher right acces to send the unauthorized page? Or maybe create an anonymous users and add it to each group?

In evo, a non accessible page redirect the user to the unauthorized page. This is a little confusing.