Password-protecting your staging site

When working on client projects, the most common workflow is to develop the site locally, and then deploy it to some sort of private staging server for the client to review. After a few iterations (ok, maybe months of iterations…) the site is ready to go live and can be deployed to the live web server.

While that work is in progress, it’s important to allow all stakeholders to have easy access to it, but you don’t want to make it public. There could be bad implications for you or your client if a search engine like Google crawled your staging site and started sending traffic to it. For this reason, it’s common to add a password to the site.

Adding a password

The problem with adding password to your staging site is that most common methods of doing that are really inconvenient. Probably the most common is to use HTTP Basic Auth (with something like an .htpasswd file) that causes the browser to pop up a terrible little username/password box.

This is less than ideal, because not only are these fiddly to set up right (and easy to get wrong) you have to issue every stakeholder with two sets of username and password credentials to access the site; one for the HTTP Basic Auth, and then a second set to log into the CMS to work on their content. It’s easy for anyone unfamiliar with that process to muddle up the sets of credentials and have a hard time accessing the site.

We thought we could do better than that, so Runway 3 introduces a feature with the imaginative name of Site Behind Login.

Site behind login

Site Behind Login takes a very simple approach. Users have one set of login credentials - their CMS user account. If Site Behind Login is enabled, any request to the website is denied unless the user is logged in. So to see a staging site, the client or stakeholder just needs to log into Runway and then all the pages become available. If a site visitor (like the Googlebot) isn’t logged in, they get an HTTP 403 Forbidden status code and no page content.

This is really an artefact of the Runway routing system. As all page requests come through a central point, we have the opportunity to apply some conditional logic and decide if the page view is allowed or not.

Enabling SBL

Site behind login is enabled as part of your configuration file. In Runway 3, config files are split up per-site and dynamically included based on host name. This makes it easy to add a configuration option (like SBL, or particular DB creds) for one instance of a site and not the others. As you might guess, the option to enable site behind login is:

define('PERCH_SITE_BEHIND_LOGIN', true);

When turned on, all page views are blocked unless the user is logged in. Instead, the visitor will be served the templates/pages/errors/403.php master page. You can customise this however you please.

What’s not protected

As this is a feature of the Runway routing system, it only impacts page views as these are the only thing that the router handles. Static files and resources are not blocked for logged-out users, as they don’t go through the routing. If someone knows the direct URL for an asset on the staging site, they will be able to access it.

In practise, that’s not a big issue. Crawlers index pages to find those assets, and you won’t have any available pages, so the URLs remain very difficult to discover. Most importantly, your client’s customers aren’t going to stumble upon the staging site and think it’s the real thing, which is ultimately the much bigger risk.