View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006143 | Composr alpha bug reports | [All Projects] General / Uncategorised | public | 2025-01-30 07:59 | 2025-01-30 15:08 |
| Reporter | Adam Edington | Assigned To | Patrick Schmalstig | ||
| Severity | Feature-request | ||||
| Status | closed | Resolution | won't fix | ||
| Summary | 0006143: v11 Requirements | ||||
| 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. | ||||
| Tags | No tags attached. | ||||
| Sponsorship open | |||||
|
|
There's more to it than Composr's hack-attack system. 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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-01-30 07:59 | Adam Edington | New Issue | |
| 2025-01-30 15:01 | Patrick Schmalstig | Assigned To | => Patrick Schmalstig |
| 2025-01-30 15:01 | Patrick Schmalstig | Status | non-assigned => closed |
| 2025-01-30 15:01 | Patrick Schmalstig | Resolution | open => won't fix |
| 2025-01-30 15:01 | Patrick Schmalstig | Note Added: 0009793 | |
| 2025-01-30 15:02 | Patrick Schmalstig | Note Edited: 0009793 | View Revisions |
| 2025-01-30 15:03 | Patrick Schmalstig | Note Edited: 0009793 | View Revisions |
| 2025-01-30 15:08 | Patrick Schmalstig | Note Edited: 0009793 | View Revisions |
