We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 17548
    • 74 Posts
    Hello:

    I have a modx 2.2.1 install that is for a seasonal website. As such, it has sat without much in the way of content updates since the fall. The public facing side works fine, but when the site manager tried to update a resource today, saving the resource seemed to fail. The "Please wait" notice comes up and the progress bar for "Saving" moves along, but it never actually saves.

    I did not change anything on the filesystem (nor did my client), and there aren't any obvious errors in the logs.

    I did a mysql db repair to no avail. Then, I upgraded to modx 2.2.7, hoping that would sort it out, but the issue is persisting.

    As far as I know, the only change on the shared hosting (site5) is that they've moved everybody on to PHP5. This didn't affect my other modx 2.2.7 site on the same shared server instance, so I'm kind of lost.

    Any ideas on where I should begin my investigation?

    Thanks


    This question has been answered by multiple community members. See the first response.

    • discuss.answer
      Look into mod_security and/or suhosin. This can be configured to refuse an incoming form posts with specified words, like "select" or "casino" or whatever the system admins have decided to refuse.
        Studying MODX in the desert - http://sottwell.com
        Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
        Join the Slack Community - http://modx.org
      • discuss.answer
        • 42146
        • 73 Posts
        it's is seemingly a site5 issue, in which they have recently made changes

        submit a ticket in backstage
        to change mod_security to Setting filtering to allow MODx manager main source file to execute over security settings
        Open your .htaccess file(s) and add the following to it.
        SecFilterEngine On
        SecFilterSelective "REQUEST_URI" "/manager/index.php" "allow,nolog"

        from http://wiki.modxcms.com/index.php/What_is_mod_security_and_how_does_it_affect_me

        i'm not sure yet if disabling it entirely for the site is best. but others have had that done with success. i just dont think it's best to have it completely disabled....
          • 17548
          • 74 Posts
          Thanks for the pointers. mod_security was the problem.
          • Having it disabled for the Manager's index.php isn't a problem; or if it is then your untrusted Manager users are going to give you bigger problems. The problems and hacking attacks will come in from the public web users, and there's seldom any need to disable mod_security for the site's main index.php file. All of your front-end forms should be thoroughly validated and sanitized before any GET or POST or REQUEST values are used anywhere. Even if the value is provided by a hidden form field or by javascript, those are easy to spoof, so all incoming data needs to be validated.
              Studying MODX in the desert - http://sottwell.com
              Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
              Join the Slack Community - http://modx.org
              • 42146
              • 73 Posts
              site5 told me they could not make a exception for manager/index.php and had to turn it off for the whole account.

              @sottwell, happen to have any references for how to properly validate and sanitize?
                • 17548
                • 74 Posts
                Site5 seems to be trying to monitor triggers and turn them off on a case-by case basis in this situation.

                Strange part: I can now edit resources but my client can't. Even when we use the same admin account.
                  • Studying MODX in the desert - http://sottwell.com
                    Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
                    Join the Slack Community - http://modx.org