Host upgrading php 8.3.16 to 8.3.19 "seemed" to cause a saving issue (406) on the general settings page, cmsb v 3.75 (build 2818) - MOD sec
3 posts by 3 authors in: Forums > CMS Builder
Last Post: May 2 (RSS)
Hello Group,
An interesting challenge just occurred...and I realize that correlation is not causation, but...
I just logged in to make a couple minor changes in cmsb, on the general settings page (wanted to change language choice from en-CA to en, and a couple other items for my client). When I clicked "save" I got a 406 error informing that something on the page violated MOD security. I logged out. Cleared cache/cookies/hist/temp, etc. and reopened Firefox and attempted it again. Therefore, I logged in to the host and disabled MOD security. Waited a few minutes. Re-cleared all and reopened Firefox again. No change. Same error. Just to be sure I opened up the site in Edge, went to general settings page, clicked 'save' and got the same 406 error. I went to other sections in cmsb and did small modifications and had no issues saving...the challenge is ONLY on the general settings page.
Reviewing the recent changes listed at the bottom of the general settings page I noticed the my client's host auto-updated PHP 8.3.16 to 8.3.19 a couple days ago. So I changed the php version to 8.2.28 and waited a few minutes. Went into the general settings again, changed the language, clicked save, and it saved like it should. So then I logged back into the host and turned MOD security on. Waited a few minutes. Logged back into the site's cmsb section, clicked 'save' on the general settings page and now get a 406 error again. Did one more test. Turned MOD sec off and was able to save the general settings. Turned MOD back on and get an error.
So I was considering re-uploading cmsb but remembered this forum. Until this week cmsb has been running as expected. I am using this same version for other sites and have not run into this issue...but those sites are not running above PHP8.2.28.
Hi Codee,
What I'd recommend (when you have time) is upgrading to the latest version of PHP your host supports and then tracking down the cause of the issue and resolving it.
If you have root access, you can check the logs and try to determine which mod_security rule is being flagged and disable it, as Jeff suggests. Or, if you have a regular web hosting account, you can turn off mod_security or ask the web host to fix it.
The way we find the "cause" is typically to reduce the content we're submitting by half until we get down to the characters that cause mod_security to be triggered. Over the last year, we've seen various hosts get false positives for things like:
- --> (from an HTML comment in a wysiwyg field)
- and 1 (from 2 bedrooms and 1/2 bath in a property listing)
- =https:// (from a GET form post with a link in a field)
- SELECT * FROM (SQL from the backend)
Sometimes web hosts add their own rules and it creates false positives. Sometimes if you ask them they'll fix the rule, othertimes they'll just disable mod_security.
Hope that helps, let me know any other questions. Let me know if you need help tracking down the cause.
interactivetools.com