devot:eeDevoted to ExpressionEngine

Using ExpressionEngine’s Built-In HTTP Authentication to Restrict Access During Development

March 20, 2009
by Ryan Masuga

While developing devot-ee.com, I realized there are at least five possible ways almost every single template can look based on what user group you’re in. Different levels of member see different things, and editors and contributors can even see drafts, edit links, etc. The main form of template access is based on user groups, so it would be easy to restrict the dev site to Super Admins (a group that always has access to everything), Editors, and any number of other groups I created and specified. The problem is, I needed to test logged-in and logged out status, and all the different member levels.

For example, one of those template variations is for the “Guests” user group, which is essentially the most basic devot:ee user – someone who shows up and may search for a few add-ons, and is never actually signed in. While in development, I don’t want guests to be able to see my dev templates at all – but I still need to test looking at the new templates as if I were a Guest user. How can I do that if I’ve set the template to ignore the Guests user group?

This is not only for the Guests group. All of the variations need to be tested, but I don’t want every user group to be able to see the site while in development. I will need to make sample dummy users in every group and test logging in as those users to make sure they’re seeing what they’re supposed to see and have access to only those things to which they should have access.

Even at its simplest (ignoring multiple user groups), I’ll still need to test {if logged_in} and {if logged_out} conditionals, and if you always have to be logged in to see the development templates, you can see where testing for {if logged_out} might be a bit difficult. You could always just not protect your development template groups or templates, but we’re not advocating that here – especially when someone guesses that your whole dev site is at your-site.com/dev/ or your-site.com/testing/ and they can see everything you’re up to. You could also go into the .htaccess file for your site (if you’re using one) and write your own HTTP authorization schemes if you have the chops to do so – but why not make use of the built-in system that ExpressionEngine provides?

The easiest way around this is to use ExpressionEngine’s HTTP Authentication along with fake accounts in a dummy user group to protect your development areas – which will still allow you to test all your template variations with accounts from your real user groups. The entire devot-ee.com dev site/area is set up this way, and it has worked great throughout the whole process so far.

Setting Up a Dummy “Front End Dev” Group

The first step is to set up a User Group for dev access. The only thing this group is good for is allowing access through the HTTP authentication. It has no other purpose. On devot:ee, I made a group called Front End Dev, and I made two users in this group (and if you think I’m going to tell you where the dev site is, and what the users are, well…that’s just a bit too radically transparent). One user was for myself (i.e. Super Admins) and the other was for contractors.

The Front End Dev users do not need any access to the control panel, and are extremely basic users – just enough permission to get through the HTTP login. In the Control Panel, go to Admin → Members and Groups → Member Groups. Towards the bottom there is a yellow box where you can “Create a new group based on an existing one.” Select “Guests” from the dropdown menu and click “Submit.” We now have a special and very basic User Group, that has no control panel access, and is separate from everything else.

Head back out to Admin → Members and Groups → Register a New Member and make a new member in this new group. Give the member whatever username and pass you want. Let’s say you’re contracting with Company X who has 3-4 people who need to see the dev area – you may want to give them a user/pass of companyx/c00ldev123, for example. You could make a little as one Front End Dev user to give to everybody, or a few different ones to hand out to different companies or contractors.

Keeping the users’ real login info (if they even have any – a dummy account allows you to give people access without having to make a user for each and every person) separate from the login info needed for the HTTP Authentication can help avoid any confusion over whether a template is doing what it should for a particular user group. Also, in separating the Front End Dev accounts and passwords from actual account passwords, you can remove someone from being able to view the front end templates without removing their user account or changing their user group, and you do this just by changing the password of the dummy Front End Dev user account.

Now that we have our Front End Dev User Group and an account with access, we need to protect the templates.

ExpressionEngine’s Template Access Restrictions

You can get to ExpressionEngine’s Template access restrictions in the control panel by going to Templates tab, selecting the group that has the template you want to protect (or templates – we’ll cover multiple templates in just a bit), and clicking the “Access” link for the template.

The top half of the next screen allows you to protect via Member Group. Towards the bottom is the checkbox for HTTP Authentication. From the EE docs:

If this setting is enabled, users will be prompted to login with their username and password to view the template using a standard HTTP Authentication dialog box. An example usage of this would be to protect an RSS/Atom feed from being viewed by unauthorized users, but still be compatible with Feed Readers that support HTTP Authentication, allowing authorized members to retrieve the feed.

If you have HTTP Authentication enabled, a small key icon will appear next to the template’s name in the Template Manager.

Our goal here is to keep the top part as simple as possible (we’re only going to allow access to one group) and check the box for HTTP Authentication. From the bottom of this page:

Enable HTTP Authentication?

If turned on, users from the allowed groups above will have to login via their username and password to view the template. This would allow you, for example, to protect an RSS/Atom feed for a restricted weblog from unauthorized users, but Feed Readers with HTTP Authentication support will be able to retrieve the feed. There are security considerations with HTTP Authentication, so please read the documentation.

If the login fails, the user will receive a 401 Not Authorized page and not the redirect template above. Also, this ability is typically only available when PHP is run as an Apache module.

The last part in red lets you know that you will only receive an HTTP/1.0 401 Unauthorized error when a login fails, so redirecting to a selected template is completely ignored with this method.

If you need more detailed info on EE Template Access, peruse the ExpressionEngine documentation on template access restriction.

All we need to do here is deny access to every group except our Front End Dev group, and check the box for HTTP Authentication. Because the selected template dropdown is ignored, we don’t have to worry about what template is showing there. Just click “Submit” and you’re all set. Now, when you visit that page in your browser you should get a prompt for access. Just enter the username/password combo for a user in the Front End Dev group and you’re in. You can now test this template with any {if logged_in} and {if logged_out} conditionals you need (because you’re not actually logged into ExpressionEngine at all), and log in with users from your various “real” User Groups for testing all the variations of your template.

That’s all there is to it.

Setting Restrictions on Many Pages at Once

It can be tedious setting permissions on each individual template. If you create a template group for a whole new section, you may have numerous templates in there that need to be restricted. There is an easier way to set restrictions than template by template. Here are the steps.

1. Click into the Templates tab, and click the link for “Template Preferences Manager” at the upper right of your Template Management screen (the link is directly below the green button for creating a new template group).
2. Select your template group (or even select multiple template groups!) at the left, and a new multi-select will appear that has all the templates listed from your selected group(s).
3. Highlight all the templates whose access you want to modify.
4. Under Template Access Restriction, set access for every user group to “No” except the Front End Dev group.
5. Select “Yes” on the “Enable HTTP Authentication?” dropdown at the bottom
6. Click “Update”

Happy Developing

The above template restriction method is what I’m using for development of the entire devot:ee site, and it’s working well. Once the templates are ready to roll, we’ll just remove the HTTP Authentication on them and be ready to rock. If you have an easier method, a different method entirely, or any suggestions, we’d love to hear about it in the comments.