The simpler media website CMS
Even if I haven't changed any options, clicking submit on the options page gets me a 500 server error.
The URL for the error is:
https://gal02.dd-b.net/zp-core/admin-options.php?action=saveoptions
The https error log file on the server is empty, so no useful information there.
Comments
Oh, and of course for a brand-new install I'm running zenphoto 1.5.9. But also should have said this is on a Dreamhost shared hosting account, configured for PHP 7.4.15 and that the db is configured for pdo_mysql.
Seems to happen only on the 'General' tab of the options page. I can change other options.
What do the Zenphoto debuglog and/or the PHP error logs say? Basically all options work the same way actually. And just to note I cannot reproduce this on our own site.
It's so basic, I wouldn't expect it to get out into the world if it actually did this everywhere. But it happened from the very beginning here (trying to set the timezone was one of the very first option things I tried to set, and I got the 500 error the first time I tried that). Other things work, I've uploaded photos, created dynamic albums from tags imported on the photos in the static albums, etc.
So, let's see; the Zenphoto debug log has only one line in it,saying the config file is missing and a setup run is required, and dating to when I first installed the software. The setup log says mod_rewrite is working (which I wondered about since the check-box for that is on the same page as the timezone, on the tab that fails).
I had to enable the PHP log and ask for debug output; but having done so, I got nothing. I did kill off the php cgi processes to make sure it would re-read the config file.
There's a weird thing now in the apache error log, which specifically relates to the options page. It's from last night, not this morning when I ran the latest iteration of the tests, so this doesn't appear each time I get the 500 error. But anyway, here is what it is:
[code][Sat Aug 28 23:19:57.618578 2021] [:error] [pid 13214:tid 3715596814080] [client 72.50.20\
1.214:19775] [client 72.50.201.214] ModSecurity: Access denied with code 418 (phase 2). O\
perator GE matched 7 at TX:anomaly_score. [file "/dh/apache2/template/etc/mod_sec3_CRS/RE\
QUEST-949-BLOCKING-EVALUATION.conf"] [line "93"] [id "949110"] [msg "Inbound Anomaly Scor\
e Exceeded (Total Score: 10)"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.2"] [tag "applic\
ation-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostn\
ame "gal02.dd-b.net"] [uri "/zp-core/admin-options.php"] [unique_id "YSsnDXfoV86yqRAy8ZN9\
DgAAAA8"], referer: https://gal02.dd-b.net/
[/code]
I found this "explanation" of the security check. https://forums.cpanel.net/threads/modsecurity-inbound-anomaly-score-exceeded.609051/
It seems to say that you are getting a HTTP 403 response to the save. Not sure what that could be since obviously you can load the options page in the first place.
Have you tried doing an apply without changing any options? Maybe there is something related to the option you are setting.
I still get the error even if I just click "apply" without changing anything.
And in fact it happens on a brand-new sub-domain hosting out of a brand-new directory, where the very first thing I do after filling out the pages setup sends me is to go to the options / general tab and click "apply". Oh, and I turned on all warnings, and didn't get any. And didn't get anything in the PHP log.
Without any further idea - do I need to say I never saw this before? - surely modsecurity is the reason here. It is probably configured too strict or wrong. Sadly I cannot help with this. But we had problems with several security extensions (e.h. Suoshin) in the past. I fear you will need your host's help here…
I've had something similar on a shared host where ModSecurity was active and set too strict. The host finally fixed this for me.
I see that Dreamhost allows you to disable ModSecurity completely. If you are having trouble deciphering why you are getting a 418 error in your log files you should contact their support.
See: https://help.dreamhost.com/hc/en-us/articles/215947927-How-do-I-enable-Extra-Web-Security-for-my-website-
Yeah, I did infer that nobody had seen this before, and apparently that nobody was running Zenphoto at Dreamhost (I did, some years ago, in some early tests, but not for years now; worked fine then). I'm checking back to the logs (the error logs hadn't quite appeared on the new site yet last night), and will be asking for help from them, pointing at mod_security.
Mod_security is turned on for this site, with the checkbox described on the in the Dreamhost article (plus that log entry makes it clear, of course).
I've put in a ticket at Dreamhost describing the situation and asking for help or at least advice.
Win! Dreamhost tech support disabled that one rule, I re-enabled "additional website security" (which is what their panel calls turning mod_security back on), waited to make sure it had taken effect, and re-ran the test (submitting the general options page, with or without changes) -- and nothing failed.
Thanks for helping me work through this!
Great that you could work it out with their support. Thanks for the follow up.