Upgrade to 2.2 – Dashboard not working

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>

Oops!..excuse me..:P

Pacq

@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.