Forum Moderators: phranque
This protects PHP, HTML and other HTTP files just fine, but I have non-HTTP files (like .TXT and files without extensions) that can be displayed without authorization if one knows the complete URL to the file. How can this be prevented? Note that I don't have access the the httpd.conf file since I'm on a shared server. Thanks in advance!
First, with neither <FilesMatch> nor <Files>, I could access hello.txt but hello.htm and hello.html required authentication.
Next, with <Files hello.htm>, I could access hello.txt and hello.html, but hello.htm required authentication.
Finally, with <Files hello.txt>, I could access all three files without authentication.
Thus, it can break the authentication for non-specified files, but it can't force files that would otherwise be unauthenticated to be authenticated. <Files> and <FilesMatch> are designed to limit the contained actions to a subset of files. I want to apply to all, thus I don't think their use is appropriate.
PHP, TXT, and <no extension> files don't require authentication to be accessed. CGI, HTML, PDF, ZIP files do require authentication
If HTM files do not require authentication, remove the question mark after the "L" in html:
<FilesMatch "\.((?i)cgi¦html?¦pdf¦zip)$">
AuthType Basic
AuthName "Protected Area"
AuthUserFile /home/content/html/ssl/.htpasswd
Require valid-user
</FilesMatch>
First, to Jim:
That's what I would have thought, but apparently, it isn't true. Here's a copy of my .htaccess file and a few links you can use to test my theory that file extensions do matter.
# don't allow anyone else to read this
<Files .htaccess>
order allow,deny
deny from all
</Files>
# if SSL module isn't installed, then die...
<IfModule !mod_ssl.c>
order allow,deny
</IfModule>
<IfModule mod_ssl.c>
SSLRequireSSL
AuthType Basic
AuthName "Test Protected Area"
AuthUserFile /home/content/k/e/n/kencrocker/html/test/.htpasswd
Require valid-user
</IfModule>
The .htaccess and .htpasswd files are in the /test directory, along with the test files. The username/password is: guest/guest
[example.com...]
[example.com...]
[example.com...]
[example.com...]
[example.com...]
[example.com...]
[example.com...]
[example.com...]
[example.com...]
The first 5 require authentication, the last 4 do not.
Next to coopster:
I think that my third test pretty much nailed the issue. If I used a <Files hello.txt> construct and I could access hello.txt without authentication, that pretty much says that no <FilesMatch> regular expression would work either. Unless you can think of a reason why I'm wrong?
[edited by: jatar_k at 11:52 pm (utc) on June 5, 2008]
[edit reason] please use example.com [/edit]
The rules in .htaccess/.htpasswd protects all files within the folder; all of them.
Not all of them, not if the rules are in the appropriate container, in this case a FilesMatch container. The rules are not applied unless the appropriate match has been made. Understanding that if one has access to the protected files, they have access to the unprotected files as well, as they should.
Apply the <FilesMatch> container code I posted to your "<IfModule mod_ssl.c>" container, flush your browser, and attempt to access a file that is accessible by the general public if they knew the direct link. The file will be served to you. Try another file with a different extension or no extension that is public and it will be served to you. Next try a file that is denied and you will be prompted to authenticate. Trust me, it works.
Ok, I'll bite. The .htaccess file in the /test directory now reads:
<...other stuff...>
<FilesMatch ".*">
SSLRequireSSL
AuthType Basic
AuthName "Test Protected Area"
AuthUserFile /home/content/k/e/n/kencrocker/html/test/.htpasswd
Require valid-user
</FilesMatch>
My goal is to authenticate access on all files in the directory. It behaves identically as my 10:11 post above. So, unless my regular expression is wrong (and it may be), I must respectfully disagree with the statement that all files are protected within a folder. That's the case at least on my system. But don't trust me, check it out for yourself!
Yes, it is true -- and absolutely. You've got some other factor at work here, such as an <Alias> or mod_rewrite, incorrect LoadModule order, or something else that is affecting the auth phase. Either that, or you can try sacrificing three chickens and depending on a magical solution... :)
Jim
Well, assuming that there is something amiss with my Apache configuration, I've opened a trouble ticket with my host (GoDaddy). They've already notified me that they've elevated it up a level, which doesn't necessarily mean anything. In case this doesn't work, do you know where I can buy three live chickens?
Ken
Success at last! Working with tech support at my hosting company (GoDaddy), it was determined that my account had Java applets enabled. Disabling Java made Basic Authentication work as advertised! I have no clue why Java would disrupt this basic feature.
Many thanks to all who took the time to respond to this thread!
Ken