Protecting your staging and development environments is as important as
protecting your production infrastructure. You can do this by adding modules to
your websites, or by modifying your settings.php
file. This page includes
the methods to help you protect your non-production environments.
Important
The following methods rely on a session cookie for access to the website. This session cookie will prevent Varnish®’s caching of pages and can cause excessive load on a production website.
You can use the Shield module to password protect your Drupal website. This modules is the preferred method for website protection.
To prevent inadvertently enabling the Shield module on your production
environment, you can add the code appropriate to your version of Drupal to
your website’s settings.php
file.
Important
Since the Shield module is not disabled through Drupal’s user interface, there will be no indication in Drupal’s user interface of why the module is disabled, nor can you enable the module from Drupal’s module page.
For Drupal 7 websites, add the following code to your website’s
settings.php
file:
if (isset($_ENV['AH_SITE_ENVIRONMENT'])) {
switch ($_ENV['AH_SITE_ENVIRONMENT']) {
case 'prod':
// Disable Shield on prod by setting the
// shield_user variable to NULL
$conf['shield_user'] = NULL;
break;
}
}
For websites running Drupal 9 or later, add the following code to your
website’s settings.php
file:
if (isset($_ENV['AH_SITE_ENVIRONMENT'])) {
switch ($_ENV['AH_SITE_ENVIRONMENT']) {
case 'prod':
// Disable Shield on prod by setting the
// shield user variable to NULL
$config['shield.settings']['credentials']['shield']['user'] = NULL;
break;
}
}
If you’re using PHP-FPM, add the following lines of code to the appropriate
settings.php
file to set an access password using HTTP basic
authentication, replacing [my_user]
and [my_pwd]
with your username
and password:
// Make sure Drush keeps working.
// Modified from function drush_verify_cli()
$cli = (php_sapi_name() == 'cli');
// PASSWORD-PROTECT NON-PRODUCTION SITES (i.e. staging/dev)
if (!$cli && (isset($_ENV['AH_NON_PRODUCTION']) && $_ENV['AH_NON_PRODUCTION'])) {
$username = '[my_user]';
$password = '[my_pwd]';
if (!(isset($_SERVER['PHP_AUTH_USER']) && ($_SERVER['PHP_AUTH_USER']==$username && $_SERVER['PHP_AUTH_PW']==$password))) {
header('WWW-Authenticate: Basic realm="This site is protected"');
header('HTTP/1.0 401 Unauthorized');
// Fallback message when the user presses cancel / escape
echo 'Access denied';
exit;
}
}
To password-protect all of your websites, including production, remove
the following line of code from the first if
statement in the preceding
code example:
&& (isset($_ENV['AH_NON_PRODUCTION']) && $_ENV['AH_NON_PRODUCTION'])
If the preceding code change is not enough, change .htaccess
inside
the IfModule mod_rewrite.c
section to add the following line at the
beginning of the section:
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
An alternate way to check which environment is in use is to use the value of
the AH_SITE_ENVIRONMENT
environmental variable (for example, prod
,
test
, or dev
) as described in Using environment variables in Drupal code and Drush commands.
Storing your password in the .htaccess
file is not necessarily
the most secure method of protection. Instead of storing the password directly,
you can store the hash of your password, and have the code evaluate it. This
approach adds a minimal amount of processing time, about 10 ms, for page loads.
Some options for hashing are available at crypt.
Alternately, change [my_pwd]
in the preceding code examples to
[my_hashed_pwd]
, and then generate the password with a random salt string.
To generate the hashed password, you must generate a random salt string
identifying the hash to be used, and use the PHP crypt()
function. You
typically need a salt from the alphabet ./0-9A-Za-z
.
Use the following PHP script to generate a 1000x sha256 hashed password (the minimum number of rounds).
<?php
// This script is based in part from code available at
// https://github.com/ircmaxell/password_compat under the MIT license
if (empty($argv[1])) {
echo "Usage: {$argv[0]} PASSWORD\n";
echo "\nPrints a sha256 crypt hashed password\n";
exit(1);
}
if (function_exists('openssl_random_pseudo_bytes')) {
$salt = openssl_random_pseudo_bytes(64);
}
else {
$salt = hash('sha512', hash('sha512', microtime() . serialize($_SERVER), TRUE), TRUE);
}
// encode string with the Base64 variant used by crypt
$base64_digits =
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/';
$bcrypt64_digits =
'./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
$base64_string = rtrim(base64_encode($salt), '=');
$salt = strtr($base64_string, $base64_digits, $bcrypt64_digits);
$prefix = '$5$rounds=1000$' . $salt;
$hash = crypt($argv[1], $prefix);
echo "\n$hash\n\n";
Even though *acquia-sites.com
default domains are protected from crawlers attempting to index
your website, custom non-production domains will still serve the default
robots.txt
file, which will leave the custom domain unprotected. You can
protect your custom domains using the preceding method, or you can use the
following method:
Add the following code to your .htaccess
file:
# Determine whether environment is production:
RewriteCond %{ENV:AH_SITE_ENVIRONMENT} !prod
# Route non-production requests to the blocking robots.txt:
RewriteRule ^robots.txt robots_block.txt [L]
Then, in a new file in your docroot
called robots_block.txt
, add the following:
User-agent: *
Disallow: /
In non-production environments, if a web spider or crawler requests a
robots.txt
file, Apache will handle the request and return the
robots_block.txt
file, which doesn’t allow crawling.
The AuthUserFile
directive in the Apache .htaccess
file sets the name
of a text file containing a list of users and passwords for user
authentication. Cloud Platform doesn’t support the use of AuthUserFile
as
its value must be either an absolute path or a path relative to the
infrastructure root, or else it will not work across different Cloud Platform
environments.