Thread Starter
pacq
(@pacq)
Hello,
Deerhunter04’s solution solved my problem…
<Files index-extra.php>
SecFilterInheritance Off
</Files>
Many thanks to Specks, Deerhunter and Whooami 🙂
Pacq
this is NOT a correct paste:
<Files index-extra.php>
SecFilterInheritance Off
</Files<
The correct way:
<Files index-extra.php>
SecFilterInheritance Off
</Files>
@otto42
WordPress has changed nothing in this area. The 2.2 version of the index-extra.php file is identical to the 2.1.3 version of the same file.
Well, this problem did not show up in my 2.1.3 install. may be there is a change in the ajax script files…
Lo de poner un .htaccess con:
<IfModule mod_security.c>
SecFilterInheritance Off
</IfModule>
me funcionó perfecto!!
Well, this problem did not show up in my 2.1.3 install. may be there is a change in the ajax script files…
Yes, the prototype.js was updated from 1.5.0_rc0 to 1.5.0. And I notice that there’s this change in there as well:
setOptions: function(options) {
this.options = {
method: 'post',
asynchronous: true,
contentType: 'application/x-www-form-urlencoded',
encoding: 'UTF-8',
parameters: ''
}
The “encoding: UTF-8” thing was added between versions. This could be some of the cause of the issue.
You could try removing that line. See if it makes a difference. It’s around line number 630. But, in essence, this is still a mod_security issue. It has a bad regex in this case, and needs to be fixed. Or better yet, disabled, as mod_security is completely useless anyway.
Just for the record I disagree that mod_sec is useless. It’s protected my server countless number of times from attacks. It just depends on the rules that you give it. I gave a way to fix the regex. It’s not necessary to remove anything from the code. What they have on there now constitutes a well formed header.
Good job Deerhunter and Whooami.
@otto42, I had removed the line in prototype.js but that didn’t help. The .htaccess solution is OK.
macbrink: Hmmm.. Oh well, I thought it was worth a shot. I have no way to test/reproduce it at the moment.
Today I’ve found that there is also a problem while deleting posts. I got a 403 error on admin-ajax.php and index.php so I have placed a .htaccess in the wp-admin directory with
<IfModule mod_security.c>
SecFilterInheritance Off
</IfModule>
So I don’t have to run into this with other files in the future
..Solved
Have the same problem but this does not seem to work for me. If I change the .htaccess-file in the wordpress directory or create a new one in /wp-admin the database breaks down.
The error-message I get in the dashboard goes:
Forbidden
You don't have permission to access /main/wp-admin/index-extra.php on this server.
Apache/1.3.33 Server at neurobash.com Port 80
What to do? (other than possibly start a new thread regarding this) Would appreciate any ideas.
maybe there is a typo in the .htaccess file, because this is the error this thread is about. I don’t see any database error in the message
mod_security is completely useless anyway
huh?
I beg to differ.
Thats absolute crap. I wonder if you would like to take a quick look at my mod_security audit.log I have it available if you are interested.
Thats such a nonsensical statement I sat and stared at this post for three minutes before going back and editing it to add this paragraph.
I honestly cannot see any reason to say that, having used it and seeing the results first hand.
Unfortunately, nothing works for me :c
I still get this crap:
Forbidden
You don’t have permission to access /wp-admin/index-extra.php on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Apache/1.3.37 Server at x.headsh0t.org Port 80
I think speck hit the nail! Instead of turning off mod_security I felt better adjusting my http.conf file. In my case the mod_securty.conf file. I have clients on my server, as virtual hosts, running WP and I don’t wish to change everyones htaccess files. 😉
I found …
# Only accept request encodings we know how to handle
# we exclude GET requests from this because some(automated)
# clients supply "text/html" as Content-Type
SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain
SecFilterSelective HTTP_Content-Type "!(^application/x-www-form-urlencoded$|^multipart/form-data;|^text/xml;)"
and changed it to …
# Only accept request encodings we know how to handle
# we exclude GET requests from this because some (automated)
# clients supply "text/html" as Content-Type
SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain
SecFilterSelective HTTP_Content-Type "!(^$|^application/x-www-form-urlencoded|^multipart/form-data|^text/xml)"
This did the trick for me.
