Warn user on install time and in reports about the presence of mod_security.

sub

The Batch API issue #320532: Batch API not working when http policy of mod_security is enabled. was fixed by ModSecurity. I think they'll pay attention if we take the time to properly demonstrate the problem.

Being security nuts, I bet they are block first, ask questions later in mindset, but fortunately they are willing to hear our response.

As one of their users, I'm glad to bug them once I understand where the problem is.

Neither ModSecurity nor Drupal are always wrong. This sort of message implies that ModSecurity is a bad thing and while that can be debated, it is not clearly so. As this patch recognizes, ModSecurity isn't going away.

I rather suspect that an increase in the popularity of ModSecurity should be an encouragement for Drupal to work with it, not discourage its use. To discourage its use will simply give rise to suspicions of insecurity by the unfamiliar and casual user. While Drupal does much to handle the security of itself, security holes do arise. My own hoster has had trouble with other drupal admins who fail to patch their sites and as a result was initially concerned to have drupal running. ModSecurity provides him with a certain level of assurance that Drupal isn't stepping outside it's bounds. I believe he's more comfortable with Drupal now as I've shows its merits and the only ModSecurity problems have been false-positives, but part of the reason I use his services is because I know he's on top of security concerns more than I am, unlike the wannabe hosters this is targeted at.

In short, can't we just all get along and sing a chorus of "Chum-by-ya, my lord, chum-by-ya!" :-)

I like the idea of a handbook page and would be willing to assist with writing if needed.

I started the handbook page at http://drupal.org/node/695902. Feel free to throw suggestions for improvement here and I'll work them in.

Is it worth adding something to the handbook page to encourage those bitten by a mod_security rule which is directly affecting Drupal operation to report the rule as a problem upstream? I use a commercially supported version of mod_security which allows me to report false positives so I'm not sure if there's an official place to deal with this or if this kind of thing just ends up on the mod_sec users mailing list?

I've noticed that some of the JIT patches and frequently updated rule sets change on a daily basis, and sometimes a really stupid rules makes it way in (usually only for 24 hours). It's always better to get daft rules fixed upstream rather than encourage people to disable them or even turn off mod_sec.

#522646: jquery.cookie.js incompatible with Apache mod_security by default is highly related.

#9: mod_security_requirement_check.patch queued for re-testing.

#522646 was fixed in ModSecurity CRS 2.0.8

Also, I think it's safe at this point to say it isn't making it into D7. I'm going to go ahead and close it. If you think it should be bumped to D8 instead, that's fine by me.

Is this still an issue? Tagging for IS update.