<![CDATA[ make ACLs easier or provide wizard - My Forums]]> https://forums.modx.com/thread/?thread=73071 <![CDATA[Re: make ACLs easier or provide wizard]]> https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-430830 sottwell Jul 21, 2012, 02:20 AM https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-430830 <![CDATA[Re: make ACLs easier or provide wizard]]> https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-430825
]]> BobRay Jul 21, 2012, 02:15 AM https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-430825 <![CDATA[Re: make ACLs easier or provide wizard]]> https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-430792 Quote from: BobRay at Jul 20, 2012, 11:03 PM
: http://bubs.modx.com

this is a new one to me. Just been using bugs.modx.com myself wink]]> christianhanvey Jul 20, 2012, 07:06 PM https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-430792 <![CDATA[Re: make ACLs easier or provide wizard]]> https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-430782
Some of your suggestions are very good, but they probably won't have any effect unless you report them individually as either bugs or feature requests here: http://bugs.modx.com

There is a solution to #1. You can set a custom permission for any Component menu item.

First, add a new permission to an existing or duplicate Policy Template. Important: make sure you have the permission before doing the next step (and flush permissions and sessions before continuing).

Then, go to System -> Actions. On the right side, right-click on the menu item, select "Update," and put the new permission in the the Permissions field. That should hide that component menu item from anyone without the custom permission.



------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html]]> BobRay Jul 20, 2012, 06:03 PM https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-430782 <![CDATA[Re: make ACLs easier or provide wizard]]> https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-430704 an easy way would be a form kind of thing (on one page) where u have some choices lol.



]]> fourroses666 Jul 20, 2012, 08:59 AM https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-430704 <![CDATA[Re: make ACLs easier or provide wizard]]> https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-417534
1. Components - only way to access (e.g. a Gallery album) is via the Components menu. If ACL allows this (via Content Editor Access Policy) then access is open to all Components. If I want to give user access to edit just one Gallery album only - then I can't do it.

2. The Components menu item in the Access Policy panel is not called 'menu_components' like all the other menu items. It sits alone near the top.

3. If I drag and drop (arrgh!!) Resources to a Resource Group I cannot always remove them. This happens if I have two Resource Groups with mainly the same Resources (usual situation I think with Admin as the first group). When I click on the Resources in the second (lower down the page)
Resource Group it is the matching Resource in the first group that is highlighted. If I choose Remove then it is the wrong Resource that is deleted.

4. As suggested the drag/drop interface is awful. Needs a re-design. At least you should be able to select all Resources and move with one click. Deleting a Resource from a Resource Group should just be drag back in opposite direction to the way add works.

5. Another vote for the simple setup. 99% of my needs are 'admin' with access to everything, and 'editor' with defined access (maybe create new document, maybe not) for defined Resources. I may want to allow create document type A but not document type B. I can't see any way to do this. If someone has access to a document type and access to create documents then they can create all document types AFAICS.

6. Have had a few issues when logged in as a 'user' such as Save button greyed out (after changes) but still works when you click it. And a few meaningless error messages on Save - such as 'Object object'. And a never ending 'Save' progress bar when using Opera browser. Everything is OK if I login as admin.

7. Some concerns over the way multi-user resource locking is working. Locks don't seem to disappear after a successful save or when a session is closed.

I come to MODx really new (3 days and counting), so sorry for stepping on any toes and if there are ways around any of these issues please let me know.

My background has been Lotus Notes/Domino which has a simple but effective ACL model.

1. There is a default user mode for anyone who has no specified access. This can be set to any level but would normally be 'Reader' access only.
2. Anyone who needs higher than the default level access has to be specified in the ACL by username or by the multi-user group they are a member of.
3. That username or group can have a defined access such as Author, Editor, Designer.
4. Each design element can override these db-wide settings with its own ACL.
5. Where there are any conflicts between users/groups access then the highest level of access is granted. So someone who is a named member of a group with Editor access but is also named or maybe in a group with Designer access will get Designer access.

So the access levels you can have might be:

Reader - read only access to documents
Author - can create and edit documents they create only
Editor - can create/edit all documents
Designer - access to design elements
Manager - all access

There is a bunch of other things too, but you can run most dbs with just these settings.

These covered 99.99% of my needs and these were dbs with 100,000's users. The other 0.01% was to persuade the customer that they could work around any other limitations.

The settings and terminology are quite intuitive and by comparison MODx ACL is totally opaque and lacks the intuitive user-centric approach.

chunkyRice did some great posts earlier. I have to agree with most of that. And BobRay also hit on one major concern I have - that I might lock myself out even though I am the creator and admin. That should always be impossible for me. If that was 100% certain then I can tinker with more settings but just for now I am not confident to experiment with the security side too much.

I'm using MODx Revo 2.2.0-pl2 (advanced) and it is exactly the template engine I want - except for this security stuff. (Thanks also to BobRay and Ben for their tutorials which was the only way I could even get started with this. When setting the mgr Context with Policy of Content Editor the last thing I expected to have to do is set the Role to SuperUser!)

Apologies again for stepping on any toes.

Ted]]> too_far_away Mar 26, 2012, 11:36 AM https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-417534 <![CDATA[Re: make ACLs easier or provide wizard]]> https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-412626
If I could design a new system for Revolution, I'd do this (though it could also probably be done as an overlay on the current system):

Port the Evo security system (people still had trouble with it, but it was at least learnable) with the following changes:

0. Give the admin Super User full rights, always.

1. Consolidate manager, resource, resource group, element, element category and file permissions (all tied to a specific role as they were in Evo), but put them on different tabs in the Create/Edit Role dialog. On the Elements tab, have a checkbox to allow access to each type of element and nothing more. On the category tab, a checkbox to allow access to each category with a slider that reveals the individual permissions for the category when the access checkbox is checked (add an execute permission for snippets and plugins that's checked by default). Do something similar with resource groups.

2. Add a contexts tab to the Create Edit role form with checkboxes for each context (including the Manager) and two sections. The first would have checkboxes for each context that allow access to the context at all. The second would be called something like "apply all permissions of this role, with checkboxes for each context. If they're all unchecked, all the the permissions of the role apply in all contexts. If one or more are checked, the permissions apply in only the checked contexts. This could also be done with a slider, like #1.

3. Add a tree_root_id field (with comma-separated IDs) to the user form, or have it be a user setting, visible only to those with access_permissions permission, and enforce it everywhere in the core code. This allows admins with only a few users to very easily restrict access to resources without messing with any other part of the security system and would provide an easy solution to the "Member Pages" problem.

4. Add a filemanager_path field to the user form (with comma-separated paths), or have it be a user setting, visible only to those with access_permissions permission and enforce it everywhere. Like #3 - provides an easy solution for restricting access to the file tree.

4.5 We could have an element_tree_root_id setting if the element folders had IDs, though I think it's probably better to handle this with role permissions and element categories as described above.

5. Let users have different roles in different user groups. If a resource or element is in a group attached to a user group, users outside the user group can't see it, and users inside the group have only the permissions granted by the role they have in the group.

I believe that everything that's possible now would be possible with this system, but it would be *way* easier to learn. The only thing we'd give up is the inheritance of permissions, which IMO does more harm than good. It's only there for convenience, since you can still grant or deny any user any permission you want without it, and the cost is that it keeps people from understanding the system, complicates the UI and the code, and slows down the system.


---------------------------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using . . . PLEASE!
MODX info for everyone: http://bobsguides.com/modx.html]]> BobRay Feb 19, 2012, 08:41 PM https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-412626 <![CDATA[Re: make ACLs easier or provide wizard]]> https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-412622
Anyway, although I understand how they work, I find it quite hard to set up Access Policy Template correctly, that's because there is a lot of caos there, I agree 100% with @chunkyRice, the Access Policy Template needs to be organized in a more meaningful way. Now it is in alphabetic order and is very difficult to choose the right setting to tick/untick. A group for each section like the one used for default template variables on Form Customization Sets would be a great improvement.]]> microcipcip Feb 19, 2012, 06:15 PM https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-412622 <![CDATA[Re: make ACLs easier or provide wizard]]> https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-412619 crunch for making the original jsfiddle document.)


Access Policy Template Groups (view jsfiddle)

Each tab represents a Template Group. The originals can be viewed when editing Policy Templates (Security > Access Controls > Policy Templates).


The current security system is very convoluted and hard to understand. In an attempt to unravel the chaos the following decisions have been made:
1. Template Groups would be used to base Access Policies on. Policy Templates could be removed.
2. The Admin Group has been split up into an Admin, Resource, Element and File & Folder Group. The original (largely overlapping) Resource, Element, Media Source and Object Groups have been merged into a single Object Group.
3. The Permissions have been given consistent names and were then grouped and sorted.
4. Since the MODX security system needs to be understood by laymen (most notably clients), all Save Permissions have been left out to be replaced by Edit Permissions. For the same reason all Load and List Permissions have been removed in favour of View Permissions.
5. A number of Permissions have been moved to the User group Access tabs. Amongst them the Permissions to access the Manager, the Resources tab, the Elements tab and the Files tab.


User Group Access Tabs (view jsfiddle)

Each tab represents an Access tab. The originals can be viewed when updating a User Group (Security > Access Controls > User Groups > Update).


It makes sense to try and match the way Template Groups are split up when creating Access Rules.
1. The Manager Access tab contains Rules specific for Manager Access and using the Top Menu.
2. The Resource Access tab contains Rules for access to the Resources tab, and for using Contexts and Resources. It also contains Rules for Resource Groups.
3. The Elements Access tab contains Rules for access to the Elements tab, and for using Elements and Property Sets. It also contains Rules for Element Categories.
4. The Files Access tab contains Rules for access to the Files tab, and for using files and directories. It also contains Rules for Media Sources.
5. Note that it's usually possible to select 'No Access' or 'All ...' (i.e. 'All Contexts').

These suggested changes leave the underlying structure of the current security system mostly intact. There are still Users, User Groups, Roles, Resource Groups and Access Policies. And after all Access Rules have been set, it should result in a security setup which is not much different from what you would get with Revo 2.2. The main differences are in (the organization of) the interface. There's some adjustments that may seem drastic, but what happens in the interface, doesn't necessarily need to happen in the code.

The whole system could probably be made even simpler, by using Authorization Levels and inheritance, as suggested by Mark Hamstra and BobRay.
Having said that...


Two things that would make Roles easier to understand and use


1. I agree with BobRay, that it would be much less confusing if Authorization Levels would be inverted. A high number should reflect a high Level, rather than the other way around. The current approach is prone to mistakes. For instance you could give Super Users a Level of 99 and Members a Level of 0.
2. Currently Roles need to be given very generic names, since they show up in every User Group. Which in itself is a problem, since not all User Groups require the same number of Roles. That means you never know what Roles are in use, and exactly what user base each Role represents. User Group specific Roles should eliminate these problems, since all names will be self explanatory and only those Roles that can be used will be shown.
]]> chunkyRice Feb 19, 2012, 04:53 PM https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=7#dis-post-412619 <![CDATA[Re: make ACLs easier or provide wizard]]> https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=6#dis-post-411621
Trying to unravel the mysteries of the ACL system, I'm beginning to understand why I and so many others are struggling to get a grip. Why doesn't MODX use the basic separation of Admin, Resource, Element, Object and Media Source as a guideline for everything that happens with security? And use it in a consistent and transparent way? It would reduce conflicts and allow for tying Policies to MODX elements in a more logical way.


Reorganising Permissions and Policies


First, the separation between Admin, Resource, Element, Object and Media Source should be consistent on the most profound level.

1. The Manager Context (mgr) should be treated as a distinct entity, separate from any other Context. This will allow us to separate Permissions applying to the Manager from those applying to something else.
2. Permissions in the Admin Template Group that apply to anything else but access to the Manager or any of the Top Menu items should be moved to another, appropriate Template Group.

Once this is done, the separation needs to be reflected in the UI by reorganising the Access tabs in the User Group settings.

3. Add a Manager Access tab. This will contain the Admin Policies. These will only apply to the Manager Context and not to any of the other Contexts.
4. On each Access tab there should be a single mandatory Generic Policy and any number of Specific Policies. Specific Policies will always overrule Generic Policies in case of a conflict. This should clarify the hierarchy between Policies.
5. When setting a Specific Policy, it should be possible to make it apply to 'Any Context', meaning any Context visible in the Resource Tree, not the Manager. This should prevent an excessive amount of Policies in a setup using many Contexts. (It might even be preferable to have Access rules applying to a specific Context, overrule conflicting rules applying to All Contexts.)

Now we can further organise and streamline the UI to support the above changes.

6. Policy Templates are based on Template Groups. Currently all preset Policy Templates have all available Permissions activated. That more or less implies Policy Templates are obsolete. Let's say we remove them and base Access Policies on Template Groups instead.
7. To simplify creating Access Policies we need to group the lists of Permissions. The jsfiddle document of crunch is a good example of how this could be done.
8. To make Permissions sort in a logical and consistent way and make them more readable, they should be given a title reflecting their action and the element they apply to.
9a. Some Permissions are obsolete. For instance: what use is it to restrict a User from logging out?
9b. Some Permissions are redundant. For instance: what does a Permission like 'Save' add on top of 'Edit'? I know sometimes it's possible to edit settings without saving them, but the basic principle is the same: you adjust a setting. Distinguishing between the two merely adds confusion, not more control.
9c. Some Permissions could (or should) be added. In the jsfiddle document of crunch there's some suggestions.


Some additional thoughts


I've suggested to include a mandatory Generic Policy for each Acces tab in the User Group settings. This assumes Object Permissions and generic Permissions specific to the Manager, Resources, Elements or Media Sources could be combined to form a single Policy. This may not be the case, I'm not sure how they relate to each other. Essential is that you could set a single, simple rule to cover all (unexpected) situations and divert from that rule with more specific ones.

When setting User Group options, it may be possible and desirable to combine the Context Acces tab with the Resource Group Access tabs. In fact, I sometimes wonder if it would make sense to restrict access to Contexts using Resource Groups, but that might lead to technical or logical problems.

Finally I'd like to say that everytime I try to bend my head around this problem, I get more convinced that a separation between the Manager and the other Contexts (at least in the UI) is essential to setting things straight.]]> chunkyRice Feb 12, 2012, 01:41 PM https://forums.modx.com/thread/73071/make-acls-easier-or-provide-wizard?page=6#dis-post-411621