We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
MODX Community Forums Archive

Answered Strange misbehaviour in using ACLs, Roles and Policies

    • 46363
    • 5 Posts
    mikepei Reply #1, 12 years, 8 months ago
    I do have a really strange problem in using acls, policies, users and groups.
    I did install MODx on two machines. One a windows machine using wamp, the other on one of my clients systems (a debian). Both installs do have the same configuration and settings.

    I copied the Content Editor policy, renamed it to Store Content Editor, added a role named StoreAdmin with authority 9, added a user group named StoreAdmins and a user named storeadm. I also connected this user to its new group with approriate policy and acls. After flushing and clearing cache, and relogin into MODx, i get a minified dashboard with less menu items, the treeview on the left side only shows the resource tab. Which means, thats what i wanted to have (see the attachment)

    But now the strange part. The same install, setting, configuration on the debian system, gives the new user full access to MODx, with all rights the super user has. Its like that the ACL system is totally ignored on the debian system.
    This effect appears both in MODx 2.2.10 and 2.2.11. Both machines have Apache 2.2, PHP 5.4 and MySql 5.1., even the loaded modules configuration of Apache and PHP are the same.

    Would be kind if someone has any hints where and what to check to get all things running fine, because after 2 days of intense debugging and code checking i am quite a bit frustrated in not being able to find the root cause of this misbehaviour.

    This question has been answered by mikepei. See the first response.

    [ed. note: mikepei last edited this post 12 years, 8 months ago.]
      • 10208 ☆ A M B ☆
      • 1,780 Posts
      Frogabog Reply #2, 12 years, 8 months ago
      Maybe a silly question, but have you checked the actual policies for specific permissions? Perhaps the templates you created on the initial install are missing or corrupted?
        Frogabog- MODX Websites in Portland Oregon
        "Do yourself a favor and get a copy of "MODX - The Official Guide" by Bob Ray. Read it.
        Having server issues? These guys have MODX Hosting perfected - SkyToaster
        • 3749
        • 24,544 Posts
        BobRay Reply #3, 12 years, 8 months ago
        You could also try turning off the compress_css and compress_js System Settings. They can cause weird behavior in the Manager on some sites.
          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
          • 46363
          • 5 Posts
          mikepei Reply #4, 12 years, 8 months ago
          Quote from: frogabog at Jan 23, 2014, 03:29 AM
          Maybe a silly question, but have you checked the actual policies for specific permissions? Perhaps the templates you created on the initial install are missing or corrupted?

          On both installs, i checked all policy templates under AccessControls / PolicyTempates - they are identical. Then i checked - under AccessControls/AccessPolicies - all the policies, also they are identical. No change of overall behaviour. Still having full access to MODx manager.

          What do you mean by 'templates i created on initial install' ? The only template i created, was duplicating the Content Editor AccessPolicy and renaming it to Store Content Editor. I checked this template as well, they are on both installs equal.
            • 46363
            • 5 Posts
            mikepei Reply #5, 12 years, 8 months ago
            Quote from: BobRay at Jan 23, 2014, 03:58 AM
            You could also try turning off the compress_css and compress_js System Settings. They can cause weird behavior in the Manager on some sites.

            I turned off both settings (they were initially On) - no change at all. The new user has still full access rights to the manager.
            Furthermore i checked all system settings on both installs. Besides pathnames, hostnames and the like - they are fully identical.
              • 3749
              • 24,544 Posts
              BobRay Reply #6, 12 years, 8 months ago
              You did do "Flush Permissions" and "Flush all Sessions" on the Security menu before testing, 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
                • 46363
                • 5 Posts
                mikepei Reply #7, 12 years, 8 months ago
                Quote from: BobRay at Jan 23, 2014, 03:27 PM
                You did do "Flush Permissions" and "Flush all Sessions" on the Security menu before testing, right?

                Yes, of cource.
                I did some more investigations on that topic. I wrote a little snippet, put it into the empty example page of the 'web' context. This snippet shows current user, current usergroup and some of the permissions.
                Then tested both installs with not being logged in, loggedin as sysadmin and logged in with storeadmin user. The result is quite surprising (see the attachment). As one can see, on the windows install, the permissions get correctly loaded, but on the debian system, all permissions get ignored (or not loaded) - giving the current user always all permissions. Even the anonymous user has full access rights.

                Can someone point me out, in which file(s) i should look into, where the permissions of a user gets loaded, i.e. as i log into the admin panel ?
                • discuss.answer
                  • 46363
                  • 5 Posts
                  mikepei Reply #8, 12 years, 8 months ago
                  Hah, finally found the solution for that curious problem.

                  After 3.5 days of deep code inspection and debugging, i did one last check. I inspected the two databases on tables related to access, policies, users, groups and the like.
                  Also on tables related to session data. There i came across the table modx_session.
                  On the windows system this table had entries, on the debian install this table was empty - hmm, why on earth ..., what the heck is ... huh

                  Something with sessions seems to be different between the two MODx installs. So i checked the complete session based environment within MODx itself and the underlying PHP environment.
                  The session parameters under System Settings were equal, but - two session parameters within the PHP environment were different. The first parameter was session.save_path - this can be ignored, the second parameter was session.auto_start - on the windows install it was Off, on the debian install it was On. Because i had no access to the php.ini on the debian system (its a shared host), i decided to put this parameter into a .user.ini file (PHP is implemented as a FastCGI-Process) - and tada, it worked.

                  Now all access rights are as they should be - as i wanted them to be.

                  It would be great, if this fact would find its way into the MODx manuals. I mean it seems to be essential for MODx to have this session value being set to Off in order to work properly when it comes to the permission system and acl. And by the way it would be nice, if someone can clarify why this setting completely disables/bypasses the overall pemission system of MODx.