Password Protecting Directories, Files or Whole Domains via a Web App
By leveraging OS X’s built-in user and group management architecture and Apache’s standard digest authentication, you can easily protect directories, files or whole domains — without ever touching a domain-specific password file. Here’s one way to do it via .htaccess or .conf files, as well as via a web app that can be switched on or off with a single checkbox in Server.app.
If you’ve come from another Apache hosting background, you’ll no doubt be familiar with directives which can be placed in .htaccess
files or .conf
files so as to require authentication before a user can view particular resources. What we can do on OS X Server, which obviously uses Apache, is both the same and a little different. First let’s take a look at the code we can use in the .htaccess
file:
AuthType Digest AuthName "Authorized Users Only" AuthUserFile /dev/null #require valid-user-name # this is OK, but more of a pain to manage require group "valid-group" # this much better, allowing group-level management
As you can see, we’re still talking to Apache, but we’re not giving it a path to a normal user password file. Instead, we’re requiring either the name of a specific valid user, or we’re requiring a user who is a member of a specific group (in this case, “valid-group”). What this means is that we can dispense with the usual practice of maintaining a separate password file for each separate site and instead simply rely on the built-in users and groups functionality of Server.app or Workgroup Manager.
And as usual, we can also wrap these directives in FilesMatch
to indicate that they should only be applied for files matched by a regular expression. For example, to protect both the login page and the admin directory of a WordPress installation, we could wrap the code above like so:
<FilesMatch "^wp-login\.php|wp-admin/.?$"> AuthType Digest... </FilesMatch>
You can also wrap these types of directives in Directory
or Location
and activate them via a web app. For example, you can control access to an entire domain — even where ProxyPass
directives might be in effect, such when using the wiki service — like so:
<Location /> AuthType Digest AuthName "Authorized Users Only" AuthUserFile /dev/null require group "valid-group" </Location>
(Using a set of directives along these lines is preferable in many ways to relying on Server.app’s built-in “Who Can Access” setting for your domains; among other things, the latter shows visitors the full server path to whatever resource they are requesting, whereas the former does not.)
You can turn this into a web app by simply saving it into a .conf
file on its own, creating a separate .plist
file which references it, and dropping those into the appropriate directories. For example, I’ve called the above httpd_grm_auth_digest_admins.conf
and reference it with a .plist
which looks like this:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>name</key> <string>net.mulhauser.webapp.auth_digest_admins</string> <key>displayName</key> <string>Auth Digest Whole Site - Admins</string> <key>includeFiles</key> <array> <string>/Library/Server/Web/Config/apache2/extra/httpd_grm_auth_digest_admins.conf</string> </array> <key>launchKeys</key> <array/> <key>proxies</key> <dict/> <key>installationIndicatorFilePath</key> <string>/Library/Server/Web/Config/apache2/extra/httpd_grm_auth_digest_admins.conf</string> <key>requiredModuleNames</key> <array/> <key>requiredWebAppNames</key> <array/> <key>sslPolicy</key> <integer>0</integer> </dict> </plist>
Placing the .conf
into .../apache2/extra/
and the .plist
into .../apache2/webapps/
(where the ellipsis is shorthand for /Library/Server/Web/Config/
) yields a simple way of protecting whole domains with a single checkbox:
(This web app is shown here alongside a few others I was testing or using at the time, some of which I’ll come back to in later articles.)
All material on this site is carefully reviewed, but its accuracy cannot be guaranteed, and some suggestions offered here might just be silly ideas. For best results, please do your own checking and verifying. This specific article was last reviewed or updated by Greg on .
https://codedmemes.com/lib/password-protecting-directories-files-domains/