---
title: "Password-protecting non-production environments"
date: "2024-02-14T06:18:38+00:00"
summary: "Secure your non-production Drupal environments with password protection. Learn multiple methods, including modules and settings.php modifications, to safeguard staging and development sites from unauthorized access."
image:
type: "page"
url: "/acquia-cloud-platform/password-protecting-non-production-environments"
id: "72a8acd1-9e67-4a1f-bd76-38e391c0ea30"
---

Table of contents will be added

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](/acquia-cloud-platform/performance/varnish/cookies#session-cookies-invalidate-caching) of pages and can cause excessive load on a production website.

Modules protecting non-production environments (preferred)
----------------------------------------------------------

You can use the [Shield](https://drupal.org/project/shield) module to password protect your Drupal website. This modules is the preferred method for 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.

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 the [current Drupal version](/service-offerings/guide/software-life-cycle#supported-drupal-version), 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']['shield_enable'] = false;
            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 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](/acquia-cloud-platform/develop-apps/env-variable).

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 [crypt](http://php.net/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";
    

Protection for custom non-production domains
--------------------------------------------

Even though `*acquia-sites.com` [default domains](/acquia-cloud-platform/manage-apps/domains#cloud-default-domain-names) 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](/definitions/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 infrastructure root, or else it will not work across different Cloud Platform environments.