Navigate
Home
ArticleWiki
Forum
Journal
Search
Newsletter
Links
Tech News
expertsrt.com
Welcome Guest.
Username:

Password:

Remember me

Apache 401 Custom ErrorDocument Problem
Welcome, Guest. Please login or register.
December 02, 2008, 08:22:06 PM
11304 Posts in 1248 Topics by 498 Members
Latest Member: katCheeme
Experts Round Table Network  |  Webservers  |  Apache  |  Apache 401 Custom ErrorDocument Problem « previous next »
Pages: [1]
Author Topic: Apache 401 Custom ErrorDocument Problem  (Read 715 times)
nicholassolutions
Administrator
*
Offline Offline

Posts: 133



WWW
« on: March 23, 2006, 12:26:23 PM »

My Apache skills are not the best, but I generally know what I'm doing. After searching around quite a bit, I've found a number of places where this problem has been encountered, but none where it has been solved. Oh right, I should tell you the problem:

I have a PHP script that handles all of my HTTP errors (e.g. 404 not found). This is done by including lines like
Code:
ErrorDocument 401 /http_error_handler

in my main http.conf file, where http_error_handler is an Alias to my PHP script.
Code:
Alias /http_error_handler /file/system/path/to/httpError.php

Using the $_SERVER['REDIRECT_STATUS'] variable, I can find out the HTTP status code and serve error messages accordingly. It works great on the main site.

However, I have a VirtualHost for an "admin" (admin.mysite.com) subdomain (that requies SSL, although I don't think that matters). There are two levels of basic http authentication protecting it. First, the entire subdomain requires authentication:
Code:
<Directory />
Order allow,deny
Allow from all
AuthGroupFile "/file/system/path/to/.htgroup"
AuthUserFile "/file/system/path/to/.htpasswd"
AuthName "Admin Area"
AuthType Basic
Require group admins
SSLRequireSSL
</Directory>

Then, a subdirectory (for higher level admins) requires another login:
Code:
<Directory "/file/system/path/to/subfolder">
Options Indexes
Order allow,deny
Allow from all
AuthGroupFile "/file/system/path/to/.htgroup"
AuthUserFile "/file/system/path/to/.htpasswd"
AuthName "Admin Area"
AuthType Basic
Require user matt
SSLRequireSSL
</Directory>


Now, if I login to the first level (the base subdomain URL), and request a page that does not exist, I get my custom 404 page, so that is working. If I try to login to the protected subfolder and the login fails, I get my custom 401 Auth Required page. However if I try to login to the main subdomain and fail, I get the default Apache 401 page, plus this error message:

"Additionally, a 401 Authorization Required error was encountered while trying to use an ErrorDocument to handle the request."

So, it seems that Apache is trying to access the custom error document, but I'm not allowed to see it because I am not logged in! The custom 401 page works on the subfolder because I'm already logged in to the admin domain from which the error page appears to be served.

The only solution I can see to this problem is to only protect subfolders, and not the subdomain as a whole, and maybe adding an automatic redirect to one of the subfolders so that admins don't have to always type the folder name on the URL. But that kind of stinks in the sense that it's a hack. Can anyone think of the "right" way to make this work?
Logged
COBOLdinosaur
ERT.com Admin

Offline Offline

Posts: 481



WWW
« Reply #1 on: March 23, 2006, 03:47:29 PM »

I don't know that I would call the re-direct a hack. I am not a  Guru on the subject, but I think a re-direct to deliver a page without having to compromise on security is not undesirable.  There may be something more elegant, but this seems to me a valid and efficient way to handel the problem.

Cd&
Logged
nicholassolutions
Administrator
*
Offline Offline

Posts: 133



WWW
« Reply #2 on: March 23, 2006, 04:03:10 PM »

Quote
There may be something more elegant, but this seems to me a valid and efficient way to handel the problem.


To be honest, I only thought of that once I was writing the question :oops: (sometimes just explaining the problem shows you a solution), and it's secure and fairly convenient from both the admin and user persective...It's really not so bad, like you say...It just seems like there's got to be a way more elegant way of doing it...OK I'll stop repeating after Roy now...
Logged
nicholassolutions
Administrator
*
Offline Offline

Posts: 133



WWW
« Reply #3 on: March 23, 2006, 06:27:25 PM »

I talked to Nick on IM and he suggested using <FileMatch> to match everything *except* the error document. Spot on!  
Code:

<Directory />
Order allow,deny
Allow from all

<FilesMatch "^(?!httpError\.php)">
AuthGroupFile "/file/system/path/to/.htgroup"
AuthUserFile "/file/system/path/to/.htpasswd"
AuthName "Admin Area"
AuthType Basic
Require group admins
</FilesMatch>

SSLRequireSSL
</Directory>


The key is the "^(?!httpError\.php)" which says to match any string, the left end of which is not immediately followed by "httpError.php". Not this means that a document called "httpError.phpSomeOtherText.php" would not be protected, but I think I can trust myself not to name anything like that o.O

The regex functionality in Apache 2.x (which I am using) is not the same as that in 1.x. Therefore, I'm not sure if this will work in 1.x (i.e. I don't know if 1.x supports negative lookahead)....but I think it will.

Thanks again to Nick  :notworthy:
Logged
nicholassolutions
Administrator
*
Offline Offline

Posts: 133



WWW
« Reply #4 on: March 23, 2006, 08:40:33 PM »

PS: remember that directives set in <Directory> blocks apply to subdirectories as well, unless specifically overridden. So, to protect my development subdirectory, where only I should be allowed to play, I needed to wrap my Require in another <FilesMatch>

Code:

<Directory /dev>
#other directives here

<FilesMatch ".*">
AuthName "Development Access"
Require user matt
</FilesMatch>

</Directory>


I initially thought that I could just include the Require directive anywhere I wanted to within the subdirectory's <Directory> block, but I was unhappy to find that any user in the admins group could get in, so I finally tried wrapping it in <FilesMatch> and that solved the problem. Actually, just using <Files "*"> worked just as well, so I used that instead.

As far as I can tell, this is actually a bug: the files should not be served unless ALL of the security conditions are met. I'd assume that it has to do with some kind of short circuit execution somewhere, or something. That or I am just missing something... :scratch:

Either way, this works, and at the moment I don't have time to file one of those bug reports where the developers tell you don't know what you're talking about...Moral of the story: Always check to make things are working like they should be in real life, whether the code makes sense or not.
Logged
Pages: [1]
« previous next »
    Jump to: