Using Basic Auth with HTTP-to-HTTPS rewrites

[David Gibson]

I have been having problems in adding password protection to pages on the BCA server, whilst using the https protocol. It turns out it was partly my fault, and partly a bad configuration of the server.

SUMMARY: the BCA server does not provide a default setting for errordocument, which has lead to arcane problems when trying to map HTTP to HTTPS.

SOLUTION: You may wish to add the relevant settings to your .htaccess file.

DETAIL...
First of all, as noted earlier (http://british-caving.org.uk/phpBB3/vie ... =31&t=1394) I had included a rewrite in my .htaccess file, to map non-https URLs to https, to 'encourage' customers to use the https addresses. I found, though, that this seemed to cause a Basic Auth operation to fail. (i.e. a page where you need a password to access it). This proved very hard to debug, because browsers cache the WWW-Authenticate results, and there is no easy way to log out of a Basic Auth login. (I found that even closing and re-opening my browser would not clear the Authentication cache - isnt it annoying when browsers try to be helpful?). However, I eventually realised that - apart from some annoying typos in my rewrites (e.g. the value of {REQUEST_URI} begins with a /) - the problem was that the BCA server does not provide a default setting for errordocument. (I reported this to BCA "some years ago" but my report may have been overlooked). Until this is fixed, you may wish to to add the following lines to your .htaccess file.

Code: Select all

# Configure error documents
# -------------------------
ErrorDocument 401  default
ErrorDocument 403  default
ErrorDocument 404  default
ErrorDocument 500  default

I have not worked out the precise mechanism of the fault, but it is clearly an arcane combination of not being able to find an error document and trying to map that fact from an http to an https URL. This caused an attempt to try to log in to the http page to result in the procedure aborting with the message (from the https server) 401.shtml was not found on this server. Adding the above lines cured my problem, only to reveal a second one.

(Actually, I added those lines back in 2010, but I didnt include the 401 line, as it made by localhost server crash. But now, with more recent files, its OK, so Ive finally added the 401 default too)

The second problem... Suppose the user goes to a Basic Auth page with the http protocol and is then logged in? ... Because of my rewrite, he is then asked to log in to the https page because, to the browser, this is a separate realm. Thus he receives two login dialogues. This is solved by adjusting the rewrite so that it does not attempt to rewrite pages in a Basic Auth realm. Something like this...

Code: Select all

RewriteEngine on

# IF...  this is not already an HTTPS request
# AND... we are not at localhost (because I do not have an https server there)
# AND... we are not in a Basic Auth realm (/check_auth/ in this example)
# THEN...dont capture the optional www; capture the rest of the host
# AND... form the new URL as an https protocol + host + request_uri

RewriteCond %{HTTPS}        off
RewriteCond %{HTTP_HOST}    !^localhost$              [NC]
RewriteCond %{REQUEST_URI}  !^/check_auth             [NC]
RewriteCond %{HTTP_HOST}    ^(?:www\.)?(.+)           [NC]
RewriteRule ^               https://%1%{REQUEST_URI}  [R=302,L]

# NB: rewrite rule back-references ($N) are to the RewriteRule pattern
# NB: rewrite rule back-references (%N) to the last matched RewriteCond pattern

Of course, in the normal state of affairs, the user would click a link on your page to go to the protected realm; and if that is simply an address on the local server (i.e. a URI without any protocol stated) then there is no difficulty. The problem only arises if you allow the user to type the address of a Basic Auth realm into his browser and his browser defaults to http; or you have a link on an external site which includes an http protocol in the URL.

[David Cooke]

SUMMARY: the BCA server does not provide a default setting for errordocument, which has lead to arcane problems when trying to map HTTP to HTTPS.

Until this is fixed, you may wish to to add the following lines to your .htaccess file.

Code: Select all

# Configure error documents
# -------------------------
ErrorDocument 401  default
ErrorDocument 403  default
ErrorDocument 404  default
ErrorDocument 500  default

The BCA Server does provide default error pages but it then goes on to attempt to display the user's custom error page as well and errors if it is not present (it should test for the presence of the file first). I agree this isn't ideal behaviour but adequate in most circumstances.

You can create your own custom error pages in the cPanel->Advanced->Error Pages which should avoid the problem (and possibly those extra rewritecond).

This will create files like 401.shtml in your home directory. If you want to go back to square one, simply delete these files.

Or add David's code above to your .htaccess file.

[David Gibson]

The BCA Server does provide default error pages

I agree. But that was not my complaint. My complaint was that it did not provide a default setting for errordocument - which it doesnt!

but it then goes on to attempt to display the user's custom error page as well and errors if it is not present (it should test for the presence of the file first). I agree this isn't ideal behaviour but adequate in most circumstances.

Is it adequate? It results in the server displaying unnecessary error messages to the majority of customers (Viz: "Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request". Should the server be issuing "alarming" error messages to customers when it doesnt need to? I was of the opinion that "errordocument default" should be in the main Apache config file. Although... thinking about it further, I think I can see why an Admin. might not want to do that. Anyway, it has caused me quite a large amount of wasted time this week. On the other hand, I have learnt lots of related stuff that will no doubt come in useful one day.