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.
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, 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:
If the preceding code change is not enough, change .htaccess inside the IfModulemod_rewrite.c section to add the following line at the beginning of the section:
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";
Protection for custom non-production domains
Even though *acquia-sites.comdefault 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 infrastructure root, or else it will not work across different Cloud Platform environments.
Password-protecting non-production environments
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.
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, 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:
If the preceding code change is not enough, change .htaccess inside the IfModulemod_rewrite.c section to add the following line at the beginning of the section:
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";
Protection for custom non-production domains
Even though *acquia-sites.comdefault 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 infrastructure root, or else it will not work across different Cloud Platform environments.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Cloud Platform