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


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.

Modules protecting non-production environments

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

Enabling Shield only on non-production environments

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.


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;

For websites running Drupal 8 or greater, 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;

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 username and password:

// Make sure Drush keeps working.
// Modified from function drush_verify_cli()

$cli = (php_sapi_name() == 'cli');


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';

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:


If the preceding code change is not enough, then 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.

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, about 10 ms, for page loads. Some options for hashing are available at

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


// This script is based in part from code available at
// under the MIT license

if (empty($argv[1])) {
    echo "Usage: {$argv[0]} PASSWORD\n";
    echo "\nPrints a sha256 crypt hashed password\n";

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 =
$bcrypt64_digits =

$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 * 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.

AuthUserFile in .htaccess is not supported in Cloud Platform

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 server root, or else it will not work across different Cloud Platform environments.