Admin settings: clicking save 403 forbidden page
Afternoon everyone.
I've just installed the latest version of Bludit 3.6.1 on one of my shared servers and everything seems to be running great... with one exception. If I attempt to change any settings in /admin/settings (by which I mean any tab - general, advanced, logo etc) clicking save just generates a 403 forbidden page. I don't seem to have any other problem with bludit that I have noticed. I'm able to post content, change theme, add and activate plugins just not modify any settings.
Anyone have any ideas what could be causing this? Or culprit files I could look at? Or file/folder permissions that could be behind this?
I've just installed the latest version of Bludit 3.6.1 on one of my shared servers and everything seems to be running great... with one exception. If I attempt to change any settings in /admin/settings (by which I mean any tab - general, advanced, logo etc) clicking save just generates a 403 forbidden page. I don't seem to have any other problem with bludit that I have noticed. I'm able to post content, change theme, add and activate plugins just not modify any settings.
Anyone have any ideas what could be causing this? Or culprit files I could look at? Or file/folder permissions that could be behind this?
I saw a similar case with another user, for some reason the hosting was blocking the POST method in that URL. The user contact support, and they fix it... is really strange this behaviour.
It really is since it isn't affecting anything else. I've just been through all the file permissions and ownership details for all the files involved and... nothing. I will get in touch with my host and see what can be done. Does the users page use the same method as the settings page?
Thanks for getting back to me diego.
Any suggestions for anything else I could check while I wait for their response?
Update:
Turns out this was a mod security false positive. No clear way to avoid this in future on a lot of web hosts (certainly not on mine anyway as I don't have direct access to mod security). Just a bizarre and maddening peculiarity!
Thanks for getting back to me diego.
Any suggestions for anything else I could check while I wait for their response?
Update:
Turns out this was a mod security false positive. No clear way to avoid this in future on a lot of web hosts (certainly not on mine anyway as I don't have direct access to mod security). Just a bizarre and maddening peculiarity!
Yes it's really strange, I been login to one of that hosting and doing testing, also I changed the endpoint /settings for another but still the problem, I don't know exactly why is a security issue and they block the method POST, maybe the lenght.
Hi everyone,
I´m new here ... and with bludit.
After the installation I had the mentioned Message ...
My Hoster provides Plesk to administer my Hosting, also the "Web Application Firewall". In the logs of it was following entry:
ModSecurity: [file "/etc/httpd/conf/modsecurity.d/rules/tortix/modsec/50_plesk_basic_asl_rules.conf"] [line "179"] [id "XXXXXXX"] [rev "294"] [msg "Protected by Atomicorp.com Basic Non-Realtime WAF Rules:
URL detected as argument, possible RFI attempt detected"] [data "%TX:1,TX:1"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Match of "beginsWith %{request_headers.host}" against "TX:1" required.
I disabled the rule with the ID XXXXXXX ... and now it works. So the before mentioned suggestion seems to bee right and I hope this log entry helps somebody to solve this problem faster ...
CU
xelaac
I´m new here ... and with bludit.
After the installation I had the mentioned Message ...
My Hoster provides Plesk to administer my Hosting, also the "Web Application Firewall". In the logs of it was following entry:
ModSecurity: [file "/etc/httpd/conf/modsecurity.d/rules/tortix/modsec/50_plesk_basic_asl_rules.conf"] [line "179"] [id "XXXXXXX"] [rev "294"] [msg "Protected by Atomicorp.com Basic Non-Realtime WAF Rules:
URL detected as argument, possible RFI attempt detected"] [data "%TX:1,TX:1"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Match of "beginsWith %{request_headers.host}" against "TX:1" required.
I disabled the rule with the ID XXXXXXX ... and now it works. So the before mentioned suggestion seems to bee right and I hope this log entry helps somebody to solve this problem faster ...
CU
xelaac
There are several triggered ModSecuirty rules associated with your domain. ModSecurity is an Apache module which works as a web application firewall. It blocks known exploits and provides protection from a range of attacks against web applications. However, sometimes, mod_security may incorrectly determine that a certain request is malicious, while it is actually legitimate.
Whitelisted all triggered rules.
Whitelisted all triggered rules.