#6143 - v11 Requirements
| Identifier | #6143 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | v11 Requirements |
| Status | Closed (rejected) |
| Handling member | Deleted |
| Addon | General / Uncategorised |
| Description | "turn ModSecurity off, or set it to detection only (Composr has its own built-in Web Application Firewall, and ModSecurity will interfere with Composr's functionality)"
Unless end users are using their own server or have control over this, it would make more sense to be able to disable Composr's WAF (if they are going to conflict). I doubt my webhost would disable ModSecurity. |
| Steps to reproduce | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".


Comments
ModSecurity also interferes with other functionality involving form field parameters and AJAX requests. Composr tries to work around these issues automatically, but it is not perfect.
ModSecurity use with Composr is not officially supported by the core developer team, although I took on ModSecurity testing / fixes through PDStig, LLC. So if you notice any specific ModSecurity issues happening that Composr is not working around, please open a specific tracker issue for each problem you find, and I'll take a look.
The Composr "WAF" cannot be fully disabled, and for good reason. Your site will be wide open to attacks if it is. The cons of implementing functionality to disable it far outweigh the pros. Even if we take away the factor of user trust, and developers assume trust that users know what they are doing... implementing such an option adds an additional point of failure where hackers can go in, disable your WAF, and then hack your site. Therefore, I will be closing this request.
You can partially disable it by editing the Advanced Banning XML so that every code has the attribute silent_to_user="true" and risk_score="0". I highly advise against doing this though.
When you do this, the WAF is still active, but it will try filtering out bad parameters or doing other alternate things instead of bombing out completely (or will throw an internal error otherwise). And setting a risk score of 0 means no one will ever get automatically banned (although you can also turn automatic banning off in your security settings instead).
NOTE: I implemented some fixes for the hack-attack system which I don't think have been released yet. So doing the above might not fully work until 11 beta 7.