AJAX Error with mod_security enabled [#370651]

I'm getting what I thought at first was the same ajax error (as #295246: An error occurred at /drupal/admin/build/views/ajax/preview/) but I'm using views 6.x-2.3 which incudes the fix to that problem! However, I now think it's not the same.

The error is "An error occurred at /admin/build/views/ajax/config-item/calendar/default/filter/status" (or similar - it happens whatever setting I try to edit). If I disable javascript for views it works OK.

I haven't created or edited any views myself, just trying to edit views created by other modules (in particular, the calendar module but also draft_list and date_browser views, ). I tried disabling all the views and re-enabling just calendar but still get it.

The fix to #295246 involves changing views_object_cache.data to LONGBLOB type, according to comment 17 on that page. However, that fix is listed as included in views-6.x-2.3 I upgraded to 6.x-2.3 this morning and ran update.php (which spotted the update and said it had changed a data type in the DB - I don't remember which one). I checked my DB with phpMyAdmin and it showed views_object_cache.data as LONGTEXT but changing it to LONGBLOB didn't help (and anyway, the key part is "LONG" as I understand it!)

However, I don't think this is the same problem. My error.log on the server lists the error as a permissions/security thing, not a DB problem. In error.log I get errors all variants (depending only on which setting I'm trying to edit) of:

[Sat Feb 07 08:14:37 2009] [error] [client 79.133.23.23] ModSecurity: Access denied with code 501 (phase 2). Match of "rx (?:^(?:application\\\\/x-www-form-urlencoded(?:;(?:\\\\s?charset\\\\s?=\\\\s?[\\\\w\\\\d\\\\-]{1,18})?)??$|multipart/form-data;)|text/xml)" against "REQUEST_HEADERS:Content-Type" required. [id "960010"] [msg "Request content type is not allowed by policy"] [severity "WARNING"] [hostname "www.nuclearfreefinland.org"] [uri "/admin/build/views/ajax/config-item/calendar/default/filter/status"] [unique_id "61e4N0g3s7cAAB0CYsUAAAAD"]

So it looks to me to be a conflict with ModSecurity not a DB problem. I have a fair amount of access to the server, but it is a shared server and turning off security features is one thing my host doesn't like doing! Anyway, I'd rather use views without javascript than an insecure server...

Anyone else met this / any ideas?

Comment	File	Size	Author
#7	370651-mod-security-hates-me.patch	10.23 KB	merlinofchaos
#7

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

merlinofchaos CreditAttribution: merlinofchaos commented 7 February 2009 at 17:13

This is the same issue that people have run into with Panels, so you might search the panels queue for mod_security and see if anything turns up. There may be ways to get around this.

To be honest, popular opinion is that mod_security doesn't actually work, so it may be that most people do end up turning it off.

Comment #2

merlinofchaos CreditAttribution: merlinofchaos commented 10 February 2009 at 21:58

Title:

Ajax errors - similar but *not* the same as #295246

» AJAX Error with mod_security enabled

Changing the title so other people might find this.

Comment #3

muschpusch CreditAttribution: muschpusch commented 29 July 2009 at 09:01

@merlinofchaos: Just enable mod_secure and have a look to log files... After that you won't say it's not working.

Add this to the whitelist.conf:

< LocationMatch "/admin/build/views/edit/date_browser" >
SecRuleEngine Off
< /LocationMatch >

Comment #4

seattlehimay CreditAttribution: seattlehimay commented 28 July 2009 at 21:30

For what it is worth, I was having the exact same problem seemingly out of the blue. Ajax errors while trying to add or edit almost any value in the view, errors in the logs stating access denied.

Turns out I was using https instead of http. Simply reloading views with the other protocol fixed the issues. Took me a while to catch, but fix is easy enough ;)

Comment #5

TwoD

Swedish

Sweden

CreditAttribution: TwoD commented 21 October 2009 at 13:26

If you can't, or don't want to, disable mod_security[2] you can try changing any data property of all AJAX calls you can find. My host had it set to filter out empty POSTS so I just needed to set data to a whitespace instead of an empty string. Same thing with the progressbar and batch scripts in Core. Other hosts may require more complex data.

Comment #6

merlinofchaos CreditAttribution: merlinofchaos commented 11 November 2009 at 19:23

BTW I figured out the fix, but haven't had a chance to roll a patch.

mod_security complains about empty POST. We just need to make sure that data includes something -- I recommend 'js=1' in all of the POST requests Views can send. That will fix the mod_security problems.