We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 38787
    • 74 Posts
    One of our websites seems to have non-functioning Access Control Lists. We don't know if this is a new thing – we have only just recently tried to implement Resource and User Groups. Following all the tutorials on the web still ends up with a 'protected' page that is viewable by the public.


    1. Created Resource Group with access to Web Context
    2. Put document in Resource Group
    3. Create User Group with Load List View access to RG and context
    4. Add user to UG
    5. Flush permissions/cache whatever
    6. Can still view the above document when not logged in

    I'm sure this is a malfunction because when I try the above steps on a fresh Revo 2.3.3 install, it works – the protected document returns the Error 404 page instead.

    I say 'fresh' because the malfunctioning site started life as Revo 2.2 and has been upgraded steadily to 2.3.3 over time. I've tried re-installing 2.3.3 over the top of it, no luck.

    The site malfunctions on both our development server and the live server. Details below.

    MODX 2.3.3 pl
    Apache 2.2 / Litespeed 6.7.1
    PHP 5.3.10 / 5.4.41
    MySQL 5.5.43 / 5.6.23

    My question is: what recourse do we have when a MODX install seems so fundamentally broken?

    On a related note, I can't get user login (via the Login snippet) to work either – no user session seems to be created.
      • 38787
      • 74 Posts
      Bump. Nobody has any crazy ideas? I would even consider attempting to export/import everything into a new MODX installation, if such a thing were possible.
        • 3749
        • 24,544 Posts
        You need to flush permissions *and* flush all sessions when you make an ACL change. It also doesn't hurt to delete all files in the core/cache directory.

        You also need to test your permission setup from another browser where you're not logged into the MODX Manager.

        When you're logged into the Manager, even in a different window, your status is ambiguous.

        All that said, you may have found a bug. It's also possible that some files didn't get overwritten when you upgraded. This is common if you us FTP to transfer the files individually.

        You did run setup after transferring the files, right?
          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
          • 38787
          • 74 Posts
          Hi BobRay,

          I have been flushing permissions, and testing in a different browser as well as 'incognito mode' to ensure there is no transference of session data. When you say "flush all sessions" do you mean the "Log out all users" menu item?

          I listed the steps to show that I followed them on two different installs, and only one of them works.

          I will try to delete all cache files, although I believe I've tried that once already.

          Yes, my upgrade method is to unzip a copy of the MODX 2.3.3 install straight over the top, which replaces everything. Then run setup.
            • 38787
            • 74 Posts
            BobRay, can I just clarify some things? Only because I'm still not as experienced with MODX 2 as I am with MODX 1.


            • A User Group needs to have Member Role and Load List View Context access
            • A User Group needs to have Member Role and Load List View Resource Group access
            • A document should be protected as soon as you put it in the above Resource Group


              • 3749
              • 24,544 Posts
              Your first two statements are false as written, though I don't think you meant them as universal statements of fact.

              This is how I look at protecting resources:

              If a resource is in a Resource Group and that Resource Group is connected to a User Group with a Resource Group Access ACL entry, the resource is protected (hidden) from anyone outside that User Group.

              Contexts aren't involved in this at all, though you're correct that users need a Context Access ACL entry in order to give them any access to resources in a particular context.

              The most common stumbling block for Evolution users moving to Revolution is the change in what roles are all about. They play a central role in Evo, but in Revo, their only role is to distinguish between users in the same group -- which really isn't necessary. In fact, except for the Administrator Group (which contains only me), my rule is to give all users the same role. It simplifies things immensely and almost never needs to be violated. If users need different access rights, I put them in different groups.

              All users who are not logged in exist as the (anonymous) user (the parentheses are part of the username) and their role is 'member'. There's a default Context Access ACL entry for them, but otherwise, I seldom use that role.

              Anyway, to see if things are really broken or not, just do this:

              1. Create a Resource Group called TestResources and put some resources in it (but not the site_start page).

              2. Connect that Resource Group to the Administrator User Group (with you as the only member) with a *Resource Group Access* ACL entry with a context of 'web' and the Policy of 'Resource' -- minimum role of anything but member.

              3. Flush everything and try to view that resource in the front end without logging in and/or after logging in as a user who is not a member of the Administrator group. You should get forwarded to the site_start page.




                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
                • 38787
                • 74 Posts
                Thanks BobRay, I'll give those instructions a shot.

                I required clarification because, as you've demonstrated, there are conflicting instructions on how to set up a 'protected' page in MODX 2. The dot points I outlined above were distilled from different sources around the internet, and add to the confusion about what appears to be a very complex function.
                  • 38787
                  • 74 Posts
                  OK I followed your instructions and the page that should be protected is still publicly viewable in a different browser, without being logged in (as I mentioned, I can't actually get "logging in" to work at all either).
                  • @atmmarketing what extras do you have installed? If you have statcache running then you would need to set the page to not be cacheable. Also did you inadvertently check the "Give Anonymous User Access" when creating the group?
                      • 38787
                      • 74 Posts
                      Quote from: jgulledge19 at Jun 25, 2015, 12:35 PM
                      @atmmarketing what extras do you have installed?

                      @jgulledge19 I have Articles, Gallery, FormIt, getResources, getPage, If, AdvSearch, FirstChildRedirect and Breadcrumbs installed. The page is not set to cacheable, I have caching turned off during development. Also, I did not check that anonymous access option. I created the Resource Group, gave it a name and that's it.