We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
  • Quote from: BobRay at Aug 23, 2013, 07:40 AM
    Have you tried turning off the compress_js and compress_css System Settings and clearing your browser cache and cookies?

    I work on 2.2.8 in Chrome constantly and haven't seen this.
    Yes, i tryed.
    I have many own sites and sites of my clients. This bug not on every site. When i`ll see this again, i`ll reply here.
      MODX Revolution expert
      Follow ME on Twitter | Feel free ask any question on MODX-club
    • I find problem, but i not find solution. Needs Jason`s help. (and looks like not perfect in security (but may be not critical))

      Major cause: nulled $_SESSION['modx.mgr.user.token'] (not undefined).
      You may set $_SESSION['modx.mgr.user.token'] = '0'; via Console and reload page. Then manager panel will work almost correctly except resource/update. Reasone: many JS objects extends element and send requests via MODX.ajax that must send not only request params, but and request headers (modAuth); See core/modx.layout.js
          Ext.Ajax.defaultHeaders = {
              'modAuth': config.auth
          };
          Ext.Ajax.extraParams = {
              'HTTP_MODAUTH': config.auth
          };


      config.auth sets in modmanagercontroller
      $siteId = $this->modx->user->getUserToken('mgr');
      .....
      $o .= '<script type="text/javascript">Ext.onReady(function() {
                      '.$state.'
          MODx.load({xtype: "modx-layout",accordionPanels: MODx.accordionPanels || [],auth: "'.$siteId.'"});
      });</script>';
      


      And when we have $_SESSION['modx.mgr.user.token'] == '0';, we have ,auth: "0". And if we send header modAuth:"0" and param HTTP_MODAUTH:"0" we got:
      $_SERVER['HTTP_MODAUTH'] == $_REQUEST['HTTP_MODAUTH'] == $this->modx->user->getUserToken($this->modx->context->get('key') ($siteId) == "0" in modconnectorresponse.

      But if we do quickly resource/update via resource_tree, we have all this params and have not problems. But if we try to update resource in full resource editor, we have not header modAuth in request and got "Access denied".
        MODX Revolution expert
        Follow ME on Twitter | Feel free ask any question on MODX-club
        • 36613
        • 328 Posts
        According to you if upgrading modx to version 2.2.9 I solve the problem?
        • Quote from: cristianb88 at Sep 02, 2013, 02:18 PM
          According to you if upgrading modx to version 2.2.9 I solve the problem?

          Upgrading to 2.2.9 will not solve any ACL problems that were created by upgrading to 2.2.7 or 2.2.8. If you upgrade from 2.2.6 or earlier straight to 2.2.9, the upgrade script is simply fixed so that it does not create the ACL problems in the first place.
            Mike Schell
            Lead Developer, MODX Cloud
            Email: [email protected]
            GitHub: https://github.com/netProphET/
            Twitter: @mkschell
          • Quote from: cristianb88 at Sep 02, 2013, 02:18 PM
            According to you if upgrading modx to version 2.2.9 I solve the problem?

            I think no. Posible fix - use standart AJAX mechanism for full resource editor (resource.panel), which will post modAuth headers correctly. Now full editor and quick editor uses different mechanisms.
              MODX Revolution expert
              Follow ME on Twitter | Feel free ask any question on MODX-club
              • 36613
              • 328 Posts
              Quote from: netProphET at Sep 02, 2013, 02:28 PM
              Quote from: cristianb88 at Sep 02, 2013, 02:18 PM
              According to you if upgrading modx to version 2.2.9 I solve the problem?

              Upgrading to 2.2.9 will not solve any ACL problems that were created by upgrading to 2.2.7 or 2.2.8. If you upgrade from 2.2.6 or earlier straight to 2.2.9, the upgrade script is simply fixed so that it does not create the ACL problems in the first place.
              But I have not done the upgrade from 2.2.7 to 2.2.8, but just installed 2.2.8 and i have this problem.
              • Quote from: cristianb88 at Sep 02, 2013, 02:48 PM
                Quote from: netProphET at Sep 02, 2013, 02:28 PM
                Quote from: cristianb88 at Sep 02, 2013, 02:18 PM
                If you upgrade from 2.2.6 or earlier straight to 2.2.9, the upgrade script is simply fixed so that it does not create the ACL problems in the first place.
                I think it`s problem for all Revo versions since 2.2.8 and may be in cause of changes in 2.2.8:
                MODX Revolution 2.2.8-pl (June 4, 2013)
                ====================================
                - Prevent empty HTTP_MODAUTH from succeeding
                $_REQUEST['HTTP_MODAUTH'] empty checking correct, but $_SERVER['HTTP_MODAUTH'] is not.
                  MODX Revolution expert
                  Follow ME on Twitter | Feel free ask any question on MODX-club
                  • 18270
                  • 68 Posts
                  Ok, so just to clarify this.... If you upgraded to 2.2.8 at all (which everyone was basically forced to do after the vulnerability was announced weeks ago), then this access denied error is an issue (presumably for most people that correctly support their sites and clients)?

                  If this is correct, we URGENTLY need a patch or a fix or some concise instructions on repairing all these 2.2.8 installs.
                  How do we repair this ACL issue? If upgrading our 2.2.8 installs up to 2.2.9 will not fix it, what will?

                  Why do we not have responses from some of the main forum moderators here? This is a really important issue that is causing a lot of client frustrations.
                    • 39827
                    • 42 Posts
                    Quote from: marcushouse at Sep 03, 2013, 01:04 AM
                    This is a really important issue that is causing a lot of client frustrations.

                    I have given the clients the option to flush all sessions. Its helps to remove the 'access denied' for a while.
                    Lets hope there will come an solution
                    • @marcushouse My comments were related to the issue of messed up custom Policy Templates following an upgrade. It seems there is at least one other unrelated issue being discussed in this thread, so I'm sorry to add to any confusion. If your issue is related to having custom Policy Templates, then I'd suggest reading back to my comments on the issue and others' responses. It's not necessarily an easy fix - I'm not sure how to do it other than manually after examining how the db records are and what you think they should be.
                        Mike Schell
                        Lead Developer, MODX Cloud
                        Email: [email protected]
                        GitHub: https://github.com/netProphET/
                        Twitter: @mkschell