Rev beta 5 permission denied for new users

When trying to login for the manager:

Permission denied!
You do not have the proper access policy permissions to view this page. If you feel this is in error, please contact your systems administrator.

This happens for every new user i create. I tried new user groups, new users, super users, but nothing. Only the original user can enter the manager.

Where i am wrong?

Because the default administrator group has a Context Access ACL with entries for both the web and mgr contexts, those are protected. No one gets access to them unless you explicitly give it to them.

That means that you have to either add your users to the administrator group; presumably with a more limited policy (based on the administrator policy but with unnecessary permissions removed), unless you want them all to be super users, or put your users in a separate user group and create Context Access ACL entries for the web and mgr contexts there.

Giving them access to the mgr context lets them log in -- the policy determines what they can do in the manager.

Giving them access to the web context (or any other contexts you create) let’s them see the resources in that context in the Resources tree -- the policy determines what they can do in the front end in that context.

If I have this right, neither of these will affect visibility of things in the front end unless you also create a Resource Access ACL with a ’web’ context.

Quote from: arx707 at Jan 21, 2010, 06:07 PM

When trying to login for the manager:

Permission denied!
You do not have the proper access policy permissions to view this page. If you feel this is in error, please contact your systems administrator.

This happens for every new user i create. I tried new user groups, new users, super users, but nothing. Only the original user can enter the manager.

Where i am wrong?

The default Context ACL for Revo provides access only to Super Users of the Administrators group. When assigning the new users to the Administrators group, you’ll need to give them a Super User role for them to access the manager OR assign a policy based on the Administrators policy to regular Members of the Administrators group.

Thank you for the replies.

It’s a bit complicated but i’ll try to understand

It is a little complicated, but very flexible and it makes sense once you understand it.

Let me put it in terms of solving your problem. Here’s what I would do (assuming that you don’t want them to be Super Users, but want them to be able to access all the resources):

1. Create a new role (let’s call it Editor) with an authority of 10.

2. Add the user(s) to the admin group with a role of Editor

3. In Access Controls | Policies, duplicate the administrator policy and rename it to AdminLite.

4. Duplicate the Resource policy and call it ResourceLite (you may want this later).

5. In Access Controls | User Groups, right click on the admin group and select "Update Group."

6. On the Context Access tab, add two new ACL entries to the grid:

a. Context: ’mgr’ Minimum Role: ’Editor’, Access Policy ’AdminLite’
b. Context: ’web’ Minimum Role: ’Editor’, Access Policy ’AdminLite’

This should solve the problem for you, but it leaves the users as Super Users. To change that, edit the AdminLite policy and remove any permissions you don’t want them to have.

That’s it.

If, later, you want to put resources in resource groups to protect them from specific users, you can create more user groups and "Update" those groups to add a Resource Group Access ACL entry for each resource group they should be able to access (context: web, minimum role: Editor, policy: ResourceLite). Then you can edit the ResourceLite policy to remove unwanted permissions.

Hope this makes sense.

It is a little complicated, but very flexible and it makes sense once you understand it.

Let me put it in terms of solving your problem. Here’s what I would do (assuming that you don’t want them to be Super Users, but want them to be able to access all the resources):

1. Create a new role (let’s call it Editor) with an authority of 10.

2. Add the user(s) to the admin group with a role of Editor

3. In Access Controls | Policies, duplicate the administrator policy and rename it to AdminLite.

4. Duplicate the Resource policy and call it ResourceLite (you may want this later).

5. In Access Controls | User Groups, right click on the admin group and select "Update Group."

6. On the Context Access tab, add two new ACL entries to the grid:

a. Context: ’mgr’ Minimum Role: ’Editor’, Access Policy ’AdminLite’
b. Context: ’web’ Minimum Role: ’Editor’, Access Policy ’AdminLite’

This should solve the problem for you, but it leaves the users as Super Users. To change that, edit the AdminLite policy and remove any permissions you don’t want them to have.

That’s it.

If, later, you want to put resources in resource groups to protect them from specific users, you can create more user groups and "Update" those groups to add a Resource Group Access ACL entry for each resource group they should be able to access (context: web, minimum role: Editor, policy: ResourceLite). Then you can edit the ResourceLite policy to remove unwanted permissions.

Hope this makes sense.

I still can’t figure how to redirect users to my unauthorized page instead of the 404 page with the new permission system.

Any idea?

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.

The bottomline is no matter what kind of document we make, whether it’s the error page | unavailable page | unauthorized page, like Evo’s habit, we should apply a permissions to each of the document.
Perhaps making an "Error Landing" Resource Group is an effective way on doing this, and all the User Groups have this RG in their "Resource Group Access"

Edit:
I assume this related with subdomain ability, which you’ll have several error pages differently.

Quote from: BobRay at Jan 23, 2010, 04:46 PM

It is a little complicated, but very flexible and it makes sense once you understand it.

Let me put it in terms of solving your problem. Here’s what I would do (assuming that you don’t want them to be Super Users, but want them to be able to access all the resources):

1. Create a new role (let’s call it Editor) with an authority of 10.

2. Add the user(s) to the admin group with a role of Editor

3. In Access Controls | Policies, duplicate the administrator policy and rename it to AdminLite.

4. Duplicate the Resource policy and call it ResourceLite (you may want this later).

5. In Access Controls | User Groups, right click on the admin group and select "Update Group."

6. On the Context Access tab, add two new ACL entries to the grid:

a. Context: ’mgr’ Minimum Role: ’Editor’, Access Policy ’AdminLite’
b. Context: ’web’ Minimum Role: ’Editor’, Access Policy ’AdminLite’

This should solve the problem for you, but it leaves the users as Super Users. To change that, edit the AdminLite policy and remove any permissions you don’t want them to have.

That’s it.

If, later, you want to put resources in resource groups to protect them from specific users, you can create more user groups and "Update" those groups to add a Resource Group Access ACL entry for each resource group they should be able to access (context: web, minimum role: Editor, policy: ResourceLite). Then you can edit the ResourceLite policy to remove unwanted permissions.

Hope this makes sense.

WOW a perfect tutorial!
thank you very much!

Hi,

I don’t know if this is the right place to post this, but I noticed the following bug:

- First create a user account with no permissions
- Have that user try to log into the manager - an error occurs
- Do the necessary magic to make the user an administrator *
- Have the user try to log in again

The user will keep seeing a login error until he clears his cache / cookies.

* Side note:

The user administration screen is really daunting. I just messed around with it until I could make a user an administrator, but I can barely remember what I did.

It would be useful to have a simple "Administrator" check box when you’re adding a new user that does all the necessary group / role / resource group magic necessary for it to work.

Better yet, in the installer, have a section to specify a list of administrators (usernames, emails and passwords).

Thanks for reading this.