Any way to restore default security in Revo?

Is there a way to restore default permissions? While trying to create some users, permissions, groups, etc., I’ve lost administrator access to my resources. Elements are still there. The "web" context is gone.

I’m running Revolution 2.0.0-pl on apache server, linux - hosted by someone else and can’t find all the version info.

I’m pretty new at all this so would appreciate any help.

Thanks,
Kirk

Here’s an update to this problem. The site works (www.grizzlyhockey.com/index.php), but web documents can’t be seen in Manager. There is no longer a "web" context and I haven’t been able to add the context. The only resource showing is "provisioner." All the elements are accessible. I can attempt to create a resource, which I did using the Base Template, but when I try to save it the "Please Wait ... saving" dialog will not go away. I can close the browser window and get back into manager at which point the "Please Wait ... saving" dialog is no longer there.

I suspect the fix is to somehow restore the "web" context. If I try to manually add it in "Manage Site Contexts" I just get "an error occurred while creating the context." Context keys present are "mgr" and "provisioner."

If you created resource groups in the manager and tied them to user groups with a Resource Group Access ACL entry, you’ve "protected" them from the admin unless the admin is a member of those user groups. Odds are good that that’s your problem.

You can either add the admin to the user groups, or update the admin user group and add Resource Group Access ACL entries for those resource groups.

There’s no simple way of reverting to the default permissions without losing all your other work.

It’s a good bet, though, that if you delete all ACL entries except the first two Context Access ACL entries in the Administrator group, you’d be back to the defaults.

Don’t forget to flush permissions (and maybe sessions) after making your changes.

Bob - you probably hit the nail on the head. I had created resource groups and assigned to user groups. And I noticed later I was probably doing things to security in two different manager sessions, one on Mac OS X Safari, the other on XP virtual machine IE. Both are on my Macbook Pro. I typically run Manager on one OS and view the web site on the other. So that probably messed things up.

I had already deleted the resource group and user groups prior to my first post, trying to get back to square one. Right now if I do what you suggest I can’t see any resources to assign to a resource group. The Element Category Access tab is there but I believe there should also be a Resource Category Access tab (tried to verify this in Revo documentation, but the rtfm.modxcms.com site is down again). Also, there is no "web" context in the drop-down box. I can see "web" context in the modx_context db table and I can see it related to user groups in the modx_access_context table. But in that latter table I don’t know what the Principal field is so that’s as far as I’ve been able to trace it.

Try this.

Create a new context called "new" and add a context access acl entry for the admin. Then find that entry in the table & change new to web (might have to the use context ID).

Sent from my iPod

Bob:

I tried that y’day but it wouldn’t let me add the context. It gave me an error message. It probably already saw the context name in the database.

I fixed it another way. I found two "web" entries in the "target" field of the modx_access_context db table. I suspected neither was assigned to a "principal" that even existed (2 and 5). So I changed the "principal" to 1, which I suspected was the Adminstrators user group (modx_membergroup_names table), and the "policy" to 1, which is "resource." Voila, I now have access to my resources.

I think this is a bug, however. The table established a relationship between the "web" context and a user group that no longer existed.

Thanks for your help on this.

If it’s a Context Access acl entry the policy should be admin not resource.

Thanks. I wondered about that and have changed it.

If higher level roles inherit all lower level role permissions, how is it possible to take "web" context access away from the Administrator Group?

Quote from: kirkhuyser at Aug 25, 2010, 03:23 PM

Thanks. I wondered about that and have changed it.

If higher level roles inherit all lower level role permissions, how is it possible to take "web" context access away from the Administrator Group?

That’s a common misunderstanding caused by the phrase "minimum role." They inherit *higher* level role permissions. So, if a policy is attached to a role, users in the group that have roles with *higher* authority numbers won’t get those permissions.

All Context Access ACL policies should be based on the Administrator policy (or a duplicate of it with fewer permissions).
All Element Category ACL policies should be based on the Element policy (or a duplicate of it with fewer permissions).
All Resource Group Access ACL policies should be based on the Resource policy (or a duplicate of it with fewer permissions).

The Administrator policy determines what you can do and see in the Manager.
The other policies determine what you can do with specific MODx objects (chunks, templates, snippets, plugins, TVs, resources, etc.).

There’s some more info here: http://bobsguides.com/revolution-permissions.html

Thanks Bob. I’m struggling with security and this helps a lot.