wp_fix_server_vars() mangles REQUEST_URI on some servers

[jrf]

Bug manifestation:

On some server setups, saving settings on any settings page which uses options.php - including the twentyeleven theme options pages - results in a You do not have sufficient permissions to access this page.-error page, even if you are the (super-)admin of the website.

The changed settings *are* however saved, but the bug obviously causes a usability issue.

The cause of the issue:

The issue is ultimately caused by (shared-)hosting companies which - for security reasons - set the $_SERVER['SERVER_SOFTWARE'] variable to MS IIS when in reality the server runs on a Linux variant.

The $_SERVER['SERVER_SOFTWARE'] variable being MS IIS causes wp_fix_server_vars() to double the query vars resulting in a mangled $_SERVER['REQUEST_URI'].

I.e.: "/wp-admin/themes.php?page=theme_options" becomes "/wp-admin/themes.php?page=theme_options?page=theme_options"

As the $_SERVER['REQUEST_URI'] variable is used by the settings_fields() function to generate the hidden form fields for the option pages, this then in turn results in a mangled _wp_http_referer form value.

I.e.: <input type="hidden" name="_wp_http_referer" value="/wp-admin/themes.php?page=theme_options?page=theme_options" />

As the options.php file, after saving the changed settings, uses the _wp_http_referer field value to redirect the page - which it then can't - , the user ends up on the You do not have sufficient permissions to access this page.-error page.

Patch/fix for the issue:

In file wp-includes/load.php change line 75 from:

if ( ! empty( $_SERVER['QUERY_STRING'] ) ) {

to

if ( ! empty( $_SERVER['QUERY_STRING'] ) && strpos ( $_SERVER['REQUEST_URI'], '?' ) === false ) {

N.B.: line number based on WP 3.3.1. trunk

Additional info:

This bug has been in the WP code base for a while. It might be useful to add this issue to the FAQ in the documentation for those users/webmasters who do not always upgrade to the latest & greatest WP version.

A user/webmaster who encounters this issue should probably get advice along the following lines:

1. Determine that the problem is really caused by this issue by verifying that they really run on Linux and by checking that the $_SERVER['SERVER_SOFTWARE'] is a MS IIS variant - they can use phpinfo() to do so.
   

2. Upgrade to a WP version which includes the above patch once it has been released.
   

3. Contact their webhost to see if they are willing to change the $_SERVER['SERVER_SOFTWARE'] variable to reflect reality.
   

4. If neither of the above is possible/works and they are sure that this bug is the cause of their problems, they can apply the following quick & dirty fix to solve it without touching the core files:
   

Add the following code to their wp-config.php file anywhere above the /* That's all, stop editing! Happy blogging. */ line.

/**
 * Quick fix for server software bug
 */
$_SERVER['SERVER_SOFTWARE'] = 'Apache';

Related bug reports found:

• #15209 $_SERVER['REQUEST_URI'] Doesn't always work correctly
• #12346 Saving settings in multiple plugins results in You do not have sufficient permissions to access this page.

This ticket has been opened as the previous two bug reports where too old to reopen.

[nacin]

The issue is ultimately caused by (shared-)hosting companies which - for security reasons - set the $_SERVERSERVER_SOFTWARE? variable to MS IIS when in reality the server runs on a Linux variant.

Can we have an example host that does this? That is insane, though I've seen worse.

[jrf]

I totally agree that it's insane ;-)

One host where I've noticed this happening is hosting.nl. For an example phpinfo() output from one of their servers, please check: ​http://test.verlaatverdriet.nu/phpinfo.htm

I've seen quite a number of support request topics in the support fora which seems to stem from this issue, so I presume that this is surely not the only host which seems to do this.

[ocean90]

MS IIS to Linux, okay, but Linux to IIS...?

[chriscct7]

No additional reports in 4 years. Closing as worksforme