Password Protecting Directories, Files or Whole Domains via a Web App

Photo of Greg

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:

Auth Digest Web App

(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 .

This site is provided for informational and entertainment purposes only. It is not intended to provide advice of any kind.