Information for: DEVELOPERS   PARTNERS

Password-protecting non-production environments

Protecting your staging and development environments is as important as protecting your production server. You can do this by simply 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

In general, these 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.

Modules that protect non-production environments

You can use the Shield module to password protect your Drupal 7 or Drupal 8 website. The Secure Site module has a beta release for Drupal 7 and a development release for Drupal 8. These modules are the preferred methods of website protection.

Enabling Shield only on non-production environments

To prevent accidentally 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

Because 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 Drupal 8 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
        $config['shield.settings']['credentials']['shield']['user'] = NULL;
        break;
    }
}

Setting basic authentication in your settings.php file

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 desired 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, simply remove the following line of code from the first if statement in the previous code example:

&& (isset($_ENV['AH_NON_PRODUCTION']) && $_ENV['AH_NON_PRODUCTION'])

If that change alone is not enough, then modify .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.

Password security in your settings.php file

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, approximately 10ms, for page loads. Some options for hashing are available at http://php.net/crypt.

Alternately, change [my_pwd] in the previous code examples to [my_hashed_pwd], and then generate the password with a random salt string. To generate the hashed password, you need to generate a random salt string that identifies the hash to be used, and use the PHP crypt() function. You usually 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";

Protection for custom non-production domains

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 previous 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 does not allow crawling.

AuthUserFile in .htaccess is not supported in Acquia Cloud

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. Acquia Cloud does not support the use of AuthUserFile as its value must be either an absolute path or a path relative to the server root, and therefore will not work across different Acquia Cloud environments.