Make WordPress Core

Opened 15 years ago

Closed 13 years ago

Last modified 13 years ago

#2397 closed defect (bug) (invalid)

URL Rewriting Interferes with HTTP Authentication

Reported by: thenerdsangle Owned by:
Milestone: Priority: high
Severity: major Version: 2.0
Component: Administration Keywords: rewrite http authentication
Focuses: Cc:


If you set a folder in the same directory as a Wordpress installation to use HTTP Basic Authentication via an .htaccess file, and then try to access that directory, you get the WordPress 404 page.

I don't have a very wide range of resources to test this in, but I'm experiencing the issue with my site, which is on site5's servers. DreamHost users have apparently experienced the same problem, as per http://wordpress.org/support/topic/55033.

Change History (16)

#1 @davidhouse
15 years ago

  • Keywords bg|reporter-feedback added

Seems to be a problem just with PHP/CGI: I can't replicate without it. Could we have the directives you've used to set up the auth please? (apart from the passwords :)) just makes sure I've set it up in the same way you have.

#2 @thenerdsangle
15 years ago

Within the directory I'm trying to protect, the .htaccess file reads:

AuthType Basic
AuthName "www.ebroder.net"
AuthUserFile "/home/scintill/.htpasswds/ebroder/passwd"

require valid-user

The weird directory structure is because I'm a secondary domain in the account of someone else who is hosting me. The .htaccess file is generated by site5's cpanel-esque area, although I don't know what I would have done differently if I put it together by hand.

Here's the .htaccess file for the domain root (there's a lot of junk for my own convenience and to deal with some files that I think were being hotlinked, among other things):

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^photos/?([^/]*)?/?([^/]*)?/?([^/]*)?/?([^/]*)?/?([^/]*)?/?([^/]*)?/?([^/]*)?/?([^/]*)?/?$ /wp-content/plugins/falbum/wp/album.php?$1=$2&$3=$4&$5=$6&$7=$8 [QSA,L]
# END FAlbum

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

# BEGIN no-www
<IfModule mod_rewrite.c>
RewriteCond %{HTTP_HOST} ^www\.ebroder\.net$ [NC]
RewriteRule ^(.*)$ http://ebroder.net/$1 [R=301,L]
# END no-www

# Files that are requested often but don't exist anymore
Redirect gone /favicon.ico
Redirect gone /uploads/removeformat.gif

# Taking care of requests for files from the old blog - I know I can redirect
# these because they don't exist in WP
Redirect permanent /permalink.php http://ebroder.net/old_blog/permalink.php
Redirect permanent /link_image.php http://ebroder.net/old_blog/link_image.php
Redirect permanent /emoticon_image.php http://ebroder.net/old_blog/emoticon_image.php
Redirect permanent /archive.php http://ebroder.net/old_blog/archive.php

# Create an easy link to PMA
Redirect permanent /pma http://ebroder.net:2082/3rdparty/phpMyAdmin/index.php
# and, because I'm unusually lazy, one to stats too
Redirect permanent /stats http://ebroder.net:2082/awstats.pl?config=ebroder.net&lang=en

# No extension necessary
Options +MultiViews

Hope this helps

  • Evan

#3 @thenerdsangle
15 years ago

I've discovered that WP only intervenes before a user is logged in.

I tried protecting the directory and temporarily disabling WP permalinks in the .htaccess file. I then accessed the protected directory and logged in, so Firefox would cache the HTTP Authentication info. I then reenabled WP in .htaccess. I can now access the directory for the duration of the browsing session.

Apparently the mod_rewrite directives catch 401 errors not being either files or directories.

#4 @thenerdsangle
15 years ago

More information that may be useful:

I manually generated an HTTP request for the folder in question (with HTTP authentication on). Here's the exchange:

HEAD /slimstat/ HTTP/1.1
Host: ebroder.net

HTTP/1.1 404 Not Found
Date: Mon, 13 Feb 2006 01:32:36 GMT
Server: Apache/1.3.34 (Unix) mod_fastcgi/2.4.2 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/ mod_ssl/2.8.25 OpenSSL/0.9.7a PHP-CGI/0.1b
WWW-Authenticate: Basic realm="www.ebroder.net"
X-Pingback: http://ebroder.net/xmlrpc.php
X-Powered-By: PHP/4.4.2
Set-Cookie: basp=7975; expires=Mon, 13 Feb 2006 01:52:39 GMT; path=/
Content-Type: text/html

#5 @thenerdsangle
15 years ago

  • Milestone set to 2.1
  • Priority changed from normal to high


I'm upping the priority on this one, because I think this has the potential to be a major issue for anyone that doesn't use their hosting exclusively for WP.

Feel free to bump it back down.

I'm still trying to do some research on my own, but I really know nothing about mod_rewrite.

Also, there's an option on the WP_Rewrite class to enable verbose rewrite rules. If you turn that on, WP becomes set to only catch a limited range of URLs, namely, those that would be blog-related. It becomes a whitelisting instead of a blacklisting. And it works. The downside is that the .htaccess file is inflated significantly.

#6 @davidhouse
15 years ago

  • Severity changed from normal to major

Using verbose rules also means you have to update your .htaccess every time you create a new Page. Ah well, at least we have a workaround.

I concur with the priority bump (so I'm bumping severity to keep in line).

#7 @thenerdsangle
15 years ago

  • Keywords reporter-feedback added; bg|reporter-feedback removed
  • Severity changed from major to normal

As per requests on wp-hackers, changing the keyword

#8 @thenerdsangle
15 years ago

  • Severity changed from normal to major

Dang it...accidentally bumped back down the severity. Fixing...

#9 @foolswisdom
15 years ago

  • Keywords reporter-feedback removed

#10 @matt
15 years ago

  • Milestone changed from 2.1 to 2.2

#11 @rob1n
14 years ago

  • Milestone changed from 2.2 to 2.3

#12 @Otto42
14 years ago

I explain this issue fully here:

And offer a workaround for people who need to do this sort of thing.

#13 @ryan
14 years ago

  • Milestone changed from 2.3 to 2.4 (next)

#14 @Otto42
14 years ago

Quickfix Suggestion for this issue:

Create a 0 byte file called "empty". Add this to the .htaccess output: "ErrorDocument 401 empty".

This prevents the problem from occurring if somebody does use password protected directories, and it doesn't do anything else at all otherwise (since WordPress doesn't generate 401 statuses). Basically, the password needed becomes a 401 response. Apache maps it to the empty file. Since the empty file exists, the RewriteCond !-f fails, the RewriteRule is not applied, WordPress never runs, and the password challenge (401 response) is returned correctly.

Alternative: If WordPress is capable of detecting the pre-existing 401 status code when started (instead of a 404 from a nonexistent file), have it return that 401 and exit. This requires PHP to actually execute though, and so is a sub-optimal solution.

#15 @thee17
13 years ago

  • Resolution set to invalid
  • Status changed from new to closed

I'm sure looking at the forums that this is solved.

This is probably too late too help you guys, but I found that simply placing the Auth code before the WP section in the .htaccess file worked just fine. Also, it helps not to add the order or allow/deny bits, as those just seem to confuse Apache on DH. The auth bit works just fine without those statements.

All real subdirectories and password protected subdirectories, and even redirected password protected subdirectories showed up fine. All non-existent pages pointed to the WP 404 page. All permalinks survived.

Edit: Also, changing the Permalinks from within WP doesn't affect the Auth code, which is outside of the area that WP modifies.

Posted 11 months ago #

#16 @lloydbudd
13 years ago

  • Milestone 2.4 deleted
Note: See TracTickets for help on using tickets.