We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 5290
    • 29 Posts
    Here's two jsfiddle documents showing what I tried to say in my previous post. (With a big thank you to 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.
      A computer program is a utilitarian typographer's dream - a functioning machine composed completely of type. (John Maeda)
      • 19369
      • 1,098 Posts
      When I tried ACLs for the first time I thought it was impossible to understand how they worked, but I have actually managed to set up everything in just two hours thanks to Bob Ray tutorial, it was very well written!

      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. [ed. note: microcipcip last edited this post 12 years, 1 month ago.]
        • 3749
        • 24,544 Posts
        I thought I'd post a more polished version of what I'd propose for the Revolution security system. It assumes that permissions are tied to Roles as they were in MODX Evolution. If I had more time, I'd do a wireframe for it.

        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
          Did I help you? Buy me a beer
          Get my Book: MODX:The Official Guide
          MODX info for everyone: http://bobsguides.com/modx.html
          My MODX Extras
          Bob's Guides is now hosted at A2 MODX Hosting
          • 39211
          • 1 Posts
          Broken things in ACL/security

          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
            • 9995
            • 1,613 Posts
            never seen this posts, i also have difficulties with the usersystem.
            an easy way would be a form kind of thing (on one page) where u have some choices lol.



              Evolution user, I like the back-end speed and simplicity smiley
              • 3749
              • 24,544 Posts
              @too_far_away: Thanks for the feedback. Never worry about stepping on toes here as long as you're clear and constructive and your tone is not too insulting (remember that the whole system is free).

              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 [ed. note: BobRay last edited this post 11 years, 8 months ago.]
                Did I help you? Buy me a beer
                Get my Book: MODX:The Official Guide
                MODX info for everyone: http://bobsguides.com/modx.html
                My MODX Extras
                Bob's Guides is now hosted at A2 MODX Hosting
                • 6038
                • 228 Posts
                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
                  • 3749
                  • 24,544 Posts
                  Sorrry. I forgot that bubs.modx.com only works for a handful of demented MODX users. wink
                    Did I help you? Buy me a beer
                    Get my Book: MODX:The Official Guide
                    MODX info for everyone: http://bobsguides.com/modx.html
                    My MODX Extras
                    Bob's Guides is now hosted at A2 MODX Hosting
                  • How odd... I am at the moment at a frustrating point in a simple game I like to play, where the only animal I haven't collected an egg from in one area is called a Bubbubs. I've been so fixated on that for the last couple of days that I didn't even notice the typo!
                      Studying MODX in the desert - http://sottwell.com
                      Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
                      Join the Slack Community - http://modx.org