Hi,

Can someone please post the proper codes to add in the .htaccess file?

I've read all the threads concerning 400, 500, etc. codes, but all I can find is the instruction for disabling mod_security completely.

I don't want to disable mod_security completely, I just want to disable it for the urls "/fupload/flash" & "?q=fupload/flash".

Thanks.

Comments

Im with the same doubt

me too, please!

Try this..

<IfModule mod_security.c>
  SetEnvIfNoCase Request_URI ^/fupload/flash$ MODSEC_ENABLE=Off
  SetEnvIfNoCase Request_URI ^/index.php?q=fupload/flash$ MODSEC_ENABLE=Off
</IfModule>

Priority:Critical» Normal

Priority:Normal» Critical

Hi dispa,

Thanks for the suggestion, unfortunately it didn't work.

However, I got it working by setting the site to online mode without adding anything in .htaccess, apparently Image FUpload doesn't work in offline mode.

A personal problem shouldn't be the reason to mark a node as "critical"!

The "not found" problem appears on some environments which can be fixed by some easy methods:
* resaving all cck related things and other image (fupload) related things
* execute update.php

Priority:Critical» Normal

It seems like I'm not the only one having the same problem, this is why I marked critical, sorry.

About the "not found" problem, thanks for the suggestion, but I solved it with another solution, all I had to do was save the settings in the FUpload settings page in the admin panel.

grandcat,

English isn't my first language, I re-read your post and I believe your solution is the same as the one I used, thanks.

If above code from #3 dispa does not work, try this instead:

SetEnvIfNoCase Request_URI /fupload/flash$ MODSEC_ENABLE=Off
SetEnvIfNoCase Request_URI /index.php?q=fupload/flash$ MODSEC_ENABLE=Off

dispa's suggestion only works if you run drupal on the root of your server. ^ in above code means "beginning of the line" and the URL against which the test is performed is everything past your hostname.
So if your drupal runs on http://yourhost/drupal/ then above should be:

SetEnvIfNoCase Request_URI ^/drupal/fupload/flash$ MODSEC_ENABLE=Off
SetEnvIfNoCase Request_URI ^/drupal/index.php?q=fupload/flash$ MODSEC_ENABLE=Off

or leave out the ^, like I did so it only matches the end of Request_URI.

By the way, I've been fighting this bug also for hours, and yes it is a bug because it doesn't log any proper error nor does it notify me of the problem with the configuration. If we can figure out mod_security is the problem, then why can't the script tell us in the first place?

Same issue.

I've tried the solutions in numbers 3 and 9, as well as
[quote]* resaving all cck related things and other image (fupload) related things
* execute update.php[/quote] from 6, and no luck.
Still get "error 403" and that's that.
I'll keep trying for a little while more before giving up.

same here, but I am getting an "error 303" instead.

I tried both #3 and #9 solutions as well as running update.php
However, I don't quite understand what this means
[quote]* resaving all cck related things and other image (fupload) related things [/quote]
Do I have to reopen and resave all cck fields in the node?

I've tried disabling mod_security completely, and even that didn't solve the problem (503 error).

should this be added to the apache2.conf or .htaccess on the drupal directory?

Tnx :-)

Normally into the Apache config. Please ask your administrator to do it.

Edit:
Sometimes, it also works to add the config into the .htaccess:
http://drupal.org/node/297452#comment-2453598

Status:Active» Fixed

Thank you grandcat :-)

I'm using a dedicated server and maybe this will be helpful for future requests.

I created a file called modsec_exceptions.conf and placed it within the apache2/conf.d folder.
The file contains:

<IfModule mod_security.c>
  SetEnvIfNoCase Request_URI ^/fupload/flash$ MODSEC_ENABLE=Off
  SetEnvIfNoCase Request_URI ^/index.php?q=fupload/flash$ MODSEC_ENABLE=Off
</IfModule>

Thanks to Trengo @ #drupal_support for excellent help !

Thank you for this piece of code =)

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.