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 permission problem after upgrade

    • 39498
    • 169 Posts
    spica8 Reply #1, 5 years, 5 months ago
    After upgrading to 2.6.5 users that are not superusers do get a modal with this:

    Code: 200 OK
{"success":false,"message":"Erlaubnis verweigert!","total":0,"data":[],"object":[]}


    The report shows:
    [2018-10-29 15:15:47] (INFO @ /www/htdocs/modx-2.6.5-pl/core/model/modx/modaccessibleobject.class.php : 34) Principal 10 does not have permission to load object of class modCategory with primary key: 32
[2018-10-29 15:15:47] (INFO @ /www/htdocs/modx-2.6.5-pl/core/model/modx/modaccessibleobject.class.php : 34) Principal 10 does not have permission to load object of class modCategory with primary key: 7
[2018-10-29 15:15:47] (INFO @ /www/htdocs/modx-2.6.5-pl/core/model/modx/modaccessibleobject.class.php : 34) Principal 10 does not have permission to load object of class modCategory with primary key: 9
[2018-10-29 15:15:47] (INFO @ /www/htdocs/modx-2.6.5-pl/core/model/modx/modaccessibleobject.class.php : 34) Principal 10 does not have permission to load object of class modCategory with primary key: 51
[2018-10-29 15:15:47] (INFO @ /www/htdocs/modx-2.6.5-pl/core/model/modx/modaccessibleobject.class.php : 34) Principal 10 does not have permission to load object of class modCategory with primary key: 41
[2018-10-29 15:15:47] (INFO @ /www/htdocs/modx-2.6.5-pl/core/model/modx/modaccessibleobject.class.php : 34) Principal 10 does not have permission to load object of class modCategory with primary key: 49
[2018-10-29 15:15:47] (INFO @ /www/htdocs/modx-2.6.5-pl/core/model/modx/modaccessibleobject.class.php : 34) Principal 10 does not have permission to load object of class modCategory with primary key: 42
[2018-10-29 15:15:47] (INFO @ /www/htdocs/modx-2.6.5-pl/core/model/modx/modaccessibleobject.class.php : 34) Principal 10 does not have permission to load object of class modCategory with primary key: 81
[2018-10-29 15:15:48] (INFO @ /www/htdocs/modx-2.6.5-pl/core/model/modx/modaccessibleobject.class.php : 34) Principal 10 does not have permission to load object of class modDocument with primary key: 30
[2018-10-29 15:15:48] (INFO @ /www/htdocs/modx-2.6.5-pl/core/model/modx/modaccessibleobject.class.php : 34) Principal 10 does not have permission to load object of class modDocument with primary key: 68
[2018-10-29 15:15:48] (INFO @ /www/htdocs/modx-2.6.5-pl/core/model/modx/modaccessibleobject.class.php : 34) Principal 10 does not have permission to load object of class modDocument with primary key: 238
[2018-10-29 15:15:48] (INFO @ /www/htdocs/modx-2.6.5-pl/core/model/modx/modaccessibleobject.class.php : 34) Principal 10 does not have permission to load object of class modDocument with primary key: 239


    Any suggestions how to handle that?

    core/cache directory already deleted, db modx_sessions truncated, acls reviewed, but still no idea whats goin on here.

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

      • 3749
      • 24,544 Posts
      BobRay Reply #2, 5 years, 5 months ago
      The resources listed in the error messages must be protected somehow in the context that the code calling the processor is running under and/or the current user is not logged in to the current context.
        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
        • 39498
        • 169 Posts
        spica8 Reply #3, 5 years, 5 months ago
        I ve checked User Group/Permissions/Context Acess and the corresponding Access Policies. But I dont find any entry that matches the log. Dont know where else to search.
          • 3749
          • 24,544 Posts
          BobRay Reply #4, 5 years, 5 months ago
          Are the resources listed (32, 7, 9, 51, etc.) in a resource group?

          If so, is that resource group connected to a User Group with a Resource Group Access ACL entry?

          If so, what is the context specified in that ACL entry.

          Is User 10 in that User Group, and if so, with what authority level?



            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
            • 39498
            • 169 Posts
            spica8 Reply #5, 5 years, 5 months ago
            Hm. I dont get it right done.
            I had one ressource group and one element category, assigned to a admin group with level 0. User 10, level 10, is is not in that group and has minor privileges. ACLs where working before upgrade.

            Clicking ressources in the ressources tree give the prompt, even if they a not in the log. Closing the prompt lets me edit the ressource, logged as user 10. So the the promt is triggered by the tree at the left and not the ressource that is in the editor?

            I had no success by configuring the ressource group, so I deleted it for know. The log now lists only problems with modCategory. Did I take the basic concept of ressource groups and categorys wrong? My expectation was: assigning a ressource group to a user group should hide the ressources for other user groups with less privileges.

            Update: I also removed the element category. There is no modCategory entry in the log any more. But the promt is still there. [ed. note: spica8 last edited this post 5 years, 5 months ago.]
              • 3749
              • 24,544 Posts
              BobRay Reply #6, 5 years, 5 months ago
              My expectation was: assigning a resource group to a user group should hide the resources for other user groups with less privileges.

              That's close. Assigning a resource group to a user group hides the resources from all users who are not in the user group when the context specified in the ACL entry is the current context. If the context of the ACL entry is 'mgr' it will hide nothing when users are in the front-end ('web' context).

              There's a 50-minute video of me explaining MODX security here: https://vimeo.com/54360208.

              There's also this: https://bobsguides.com/modx-security-permissions.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
              • discuss.answer
                • 39498
                • 169 Posts
                spica8 Reply #7, 5 years, 5 months ago
                In the end it was just one single permission: view_template
                Checking solved it.
                It was needed to show the template dropdown in the ressource.
                Dont know, why the permission was handled differently after the upgrade. Only try and error let me find it.
                  • 54741
                  • 1 Posts
                  willne225 Reply #8, 5 years, 5 months ago
                  I am the administrator on the system and logged in as such. I have tried to select the folder properties and unchecked the read only box but the files remain read only! I have several important excel workbooks that I access daily and the only way I can edit them right now is to move them out of the document folder and leave them on the desktop!
                  How can I restore write permissions within these folders and the contents firstpremiercard login? [ed. note: willne225 last edited this post 5 years, 5 months ago.]