We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 37758
    • 73 Posts
    Ok, I realise it must be user error but I still don't get this to work, so a pointer would be appreciated.
    I have the following situation:
    - everyone should have access to all front-end pages whether logged on or not
    - I have an editors group who can see all pages in the manager (call it editors1)
    - I have another group of editors who should only be able to edit pages within one section of the site (call it editors2)

    - I set up an editors1 group, given them 'web' & 'mgr' access with 'editor' role. I have given them the "Default pages" resource group access with the mgr context
    - I set up an "editors2" resource group and added the top level page to that group
    - I set up an editors2 group ACL (Security/Access controls), given it 'web' & 'mgr' access with 'editor' role. I gave the editor2 Resource Group Resource Group Access with 'mgr' context

    As far as I can see, all is in order but the users in the editors2 group can only see their section in the manager, but not on the front end while being logged in. Non logged in users can see the section on the front end. What am I doing wrong? Why is this sooooo difficult?

    Christoph
      • 42562
      • 1,145 Posts
      I think the problem is: You told the editor2 group they own editor2 resource group but you gave them a one-sided visa to enter.

      From your description:
      ...'editor' role. I gave the editor2 Resource Group Resource Group Access with 'mgr' context...
      Give the editor2 usergroup Resource Group Access with 'web' context as well ...load, list, view etc - check the minimum role.

      Note
      Once you start restricting things, i.e, binding usergroup to resource group, users get to have access only and only on the terms you specify, nothing really, will be assumed for you.

      Plus, flush permission, and possibly clear cache. Any improvement...?
      I hope your frustration becomes mitigated
        TinymceWrapper: Complete back/frontend content solution.
        Harden your MODX site by passwording your three main folders: core, manager, connectors and renaming your assets (thank me later!)
        5 ways to sniff / hack your own sites; even with renamed/hidden folders, burst them all up, to see how secure you are not.
        • 37758
        • 73 Posts
        Thanks for the quick reply. I did what you suggested again (I had tried this before, and have read and reread Bob's guides where he suggested not to add any web context unless you want to restrict things) and this time it's worked. Probably because I have it 'Load List and View' policy, as opposed to just 'Load Only' policy? So thanks, it seems to be OK, but still don't understand why I'd need to add this if I don't really want to make any restrictions?

        And yes, I am forever flushing permissions and clearing the cache which is quite cumbersome, too.
          • 37758
          • 73 Posts
          maybe just to add to my last question. For editors1, I don't have any web context set and they can view all the resources when logged on, which would seem to prove the point that no web context should be set unless you want to restrict things?
            • 42562
            • 1,145 Posts
            Things to never forget

            Look at it this way: a tourist group (Usergroup) has a pass (access) to go the Balboa Park(Context) in San Diego (your website), which is the home of all the major museums.
            Their pass might allow them to enter the Park through the front gate (web) and back gate (mgr) gates. (Context Access)

            But lo and behold, the Museums (Resource Group) themselves have a further individual requirement.
            To enter the Museum of Art through its front door (web) or back door (mgr), with their park pass, the tourist group will need further stamping. (Resource Access Policy - web or and mgr)

            Once you give a usergroup access to a resource group, they will hug it, thus preventing other usergroups from entering the museum, unless the other usergroups have booked and paid...

            Don't confuse Context Access with Resource Access
            If you give a usergroup Context Access of web or mgr, give the same usergroup a corresponding Resource web or mgr access also, if you want them to access a particular Resource Group.
            If they get Context access to the Park, through the front door (web) they need Resource Access (web) too to see or enter a restricted Museum's front door. Or if they are the first to book the Museum, they then make it restricted.

            To restrict, in frontend, a Resource group, at minimum level - other levels:
            (1) Give Context Access (web) - of course, and (2)Resource Access (web) to a usergroup.

            Access Policy signifies what the tourist group can do when they get to the Park (the Context) - can they just see the sign post only (load), can they do much more like see the walls (load, list, view) or (Administrator Goddess) break exhibitions, take pictures, create exhibitions of their own etc, if the individual Museums gave them Resource access... (Context Access does not automatically give access to a Resource Group. It opens the ground)


            If you want other groups, including the public (anonymous) to see but not touch or edit a restricted Resource Group, give them, first a Context Access, Load Only, and a Resource Access of Load, List and View.
            To prevent them from seeing the page at all but not get a 404 error instead of the unauthorized page, give them Resource Access of Load only

            - I set up an editors2 group ACL (Security/Access controls), given it 'web' & 'mgr' access with 'editor' role. I gave the editor2 Resource Group Resource Group Access with 'mgr' context
            make sure the users who could not see the frontend of editor2 had an editor role.....or else just remove their usergroup's Context Access (web)(editor role) altogether .

            Just think about it some more, practice with it, do some trial and error, create weird scenarios of your own...above all, think about it! by my beard and whiskers there is logic in't.

            This was not meant to confuse you, especially the analogy of Park and Museum....
            Cheers
              TinymceWrapper: Complete back/frontend content solution.
              Harden your MODX site by passwording your three main folders: core, manager, connectors and renaming your assets (thank me later!)
              5 ways to sniff / hack your own sites; even with renamed/hidden folders, burst them all up, to see how secure you are not.
              • 37758
              • 73 Posts
              Hmm, thank for your long explanation, but this is still driving me so mad that I'd consider giving up on ModX. I have now lost access for everyone, so my homepage is just saying "Sorry, page not found'. AAAAAAArrrgggh. I have spent hours and hours on this, it just doesn't make sense. And also, the fact that you have to clear the cache and flush permissions a million times is just madness - when it is required to do that, ModX should do that automatically on change of permissions, but that's a different rant. Anyway, any idea why that would happen???
                • 3109 ☆ A M B ☆
                • 894 Posts
                Just get rid of resource groups in order to restore access to the site for now and start over, MODX ACL are pretty difficult to understand especially if it's your first time trying to use them.

                Try using my ACL tutorial to see if that helps.

                Good Luck.
                  Benjamin Marte
                  Interactive Media Developer
                  Follow Me on Twitter | Visit my site | Learn MODX
                  • 42562
                  • 1,145 Posts
                  Care to share a link, here or on PM? There is really no need to abandon MODx

                  You have put the homepage into a Resource Group? Let's call it HomeP

                  [anonymous usergroup] should have:
                  1. Context Access (web) / Member - 9999 / Load Only
                  2. Resource Group access (HomeP) / Member - 9999 / Load List View / (web)

                  Second part is only necessary if you have thrown the homepage and other public resources into a Resource Group.
                  Don't want confusion? Leave these resources out of a Resource Group
                    TinymceWrapper: Complete back/frontend content solution.
                    Harden your MODX site by passwording your three main folders: core, manager, connectors and renaming your assets (thank me later!)
                    5 ways to sniff / hack your own sites; even with renamed/hidden folders, burst them all up, to see how secure you are not.
                    • 37758
                    • 73 Posts
                    benmarte, I have removed resource groups and tried, but it's still not working. I have only got 'default pages'.

                    [anonymous usergroup] has:

                    1. Context Access (web) / Member - 9999 / Load Only
                    2. Resource Group access (default pages) / Member - 9999 / Load List View / (web)

                    Still no joy
                      • 42562
                      • 1,145 Posts
                      I (anonymous usergroup) can access the link you gave, with absolutely no problem.
                      Try viewing the site with another browser, while being logged out, to see what I see.


                      Are there other usergroups, admin etc? give them access to (default pages) with no less permissions (Context and Resource Access) than has the anonymous usergroup.

                      I think you are trying to view the default pages while being logged in as a member of another usergroup other than anonymous.
                        TinymceWrapper: Complete back/frontend content solution.
                        Harden your MODX site by passwording your three main folders: core, manager, connectors and renaming your assets (thank me later!)
                        5 ways to sniff / hack your own sites; even with renamed/hidden folders, burst them all up, to see how secure you are not.