Welcome to the Tweaking4All community forums!
When participating, please keep the Forum Rules in mind!
Topics for particular software or systems: Start your topic link with the name of the application or system.
For example “MacOS X – Your question“, or “MS Word – Your Tip or Trick“.
Please note that switching to another language when reading a post will not bring you to the same post, in Dutch, as there is no translation for that post!
I'm actually running into this issue right now with my own Tweaking4All forum.
Certain posts simply do not post (I had it with SQL example code).
Eventually I figured out (thanks Charles at LiquidWeb for helping out!
):
Apache's mod_security simply rejected the post silently because certain words combined in a sentence made it look like an SQL injection.
See the log files of your apache server (mine is located in /usr/local/apache/logs, and called modsec_audit.log - make the post fail on your forum and use a tail modsec_audit.log).
Now to work around this one could disable the particular rule in the mod_security config file, but I'm not sure how well bbPress sanitizes a post.
I'll get back on that once I've figured out more - any feedback is most welcome.
Two related posts in thr bbPress support forum:
How to allow SQL sample code in posts?
(no satisfying answer yet on how "secure" this is)
Bottom line is this situation is that mod_security fires a false positive.
To fix this some recommend disabling mod_security - which I think is a very bad idea.
Instead you could disable the firing rule for particular pages, which you can add to:
/usr/local/apache/conf/modsec2.user.conf
or (probably cleaner):
/usr/local/apache/conf/modsec2/whitelist.conf
(Paths may vary per system)
To disable a path do something like this:
<LocationMatch "/path/to/exclude">
SecRuleRemoveID 123456
</LocationMatch>
Where "/path/to/exclude" obviously is the path where you do not want those mod_security rules, and SecRuleRemoveID the rule you'd like to exclude for this path.
The SecRuleRemoveID can be found in your mod_security log file:
/usr/local/apache/logs/modsec_audit.log
At the log entry where the false positive occurs, you'll find something like:
[id "123456"]