How can I protect development sites with Basic Auth module enabled?

Question

During development phase a dev site should be protected from being browsable by unauthorized visitors. Usually I use Basic Auth configured in the web server. This way the only information an unauthorized visitor gets is the domain name.

Drupal 8 uses Basic Auth or OAuth for REST (no Cookie method).

If you want to protect dev sites and use REST with Basic Auth you have a problem. Usually, you setup the webserver to use Basic Auth, as said above. But with Basic Auth module enabled Drupal triggers a 403 Access Denied because Drupal tries also to process the Basic Auth header.

Problems:

• The header goes also to Drupal, that tries to use it, giving you a 403 because webserver Basic Auth doesn't match with Drupal users.
• If you use two Basic Auth headers (one for the webserver or external layer, another for Drupal when consuming the REST services) you have you tweak your REST service consumers to send those two headers. Also, your webserver or external layer should remove the right header and pass header that Drupal should use.

Obvious solutions

• (Use always OAuth for REST services) It seems that OAuth uses Authorization header too so not a solution.
• Use other method to protect the dev site than Basic Auth.

Any other way to accomplish this?

NOTE: Clients have no static IP and can't use a VPN to connect (this is mainly because customers must be able to check the dev site).

Answer 1

The steps are as follows:

• Modify .htaccess to read DirectoryIndex index.html index.php
• Construct your index.html file to show whatever you need.
• Modify your robots.txt to disallow any search engine robots to index your site.

Clients can check http://www.example.com/index.php whenever they like, and you can revert your .htaccess and robots.txt when you are done.

Answer 2

During development phase a dev site should be protected from being browsable by unauthorized visitors.

One, out of the box, solution is to put the site in maintenance mode (/admin/config/development/maintenance). So only admins can view/browse the site.

To login you have to manually go to /user/login

Answer 3

This answer not solve several problems: info about site is leaked because you see the maintenance mode page that usually have a company log and other info. Also, you can only browse the site or consume the REST services as admin user, so you are unable to test/check the site with others users (for example, permissions are an issue as admin by pass all of them). You can mitigate this giving permissions to browse the site to ohter users, but you are at the end modifyng the real behavior of your site. The protection should be transparent for the site.

Fair enough, then you should use

Maintenance Exempt

Drupal allows you to set your site into maintenance mode in order to deploy code and database upgrades safely. However, access to the site during maintenance mode is by default controlled by a permission, which is generally only given to administrative users. It's not possible to test the site as a regular anonymous or authenticated user without giving all anonymous/authenticated users the "Use the site in maintenance mode" permission, so you generally have to test those things on the fly after moving the site back to "live" mode.

Until now, that is! This D7+ module (the necessary hook doesn't exist in D6 and below) allows specific people to perform the necessary testing on the site with all role combinations without opening the site up to all of your visitors.

Now, if you don't want the logo to show up in your maintenance mode page then

Copy maintenance-page.html.twig located in /modules/system/ and paste it in /sites/all/themes/[your theme]/templates folder.

Then edit the file and delete the {{ logo }} and anything else you want. Perhaps everything?

Answer 4

If you want to "Use other method to protect the dev site than Basic Auth.", you may want to have a look at my answer to the question about "How to make the permissions of a module more granular?". It uses (only) the Rules module, for which this is the summary of the included rule:

• Rules Event: Drupal is initializing.
• Rules Conditions: Check if it is an anonymous user and verify if they try to visit some URLs they do NOT have access to.
• Rules Action: Redirect those who meet the Rules Conditions to "some other URL instead" (with some informational message about it).

By adapting the URLs used in these Rules Conditions and Actions, you might be close to what you're looking for.

This rule works perfectly in Drupal 7, but I haven't tested it in a Drupal 8 setup yet. But maybe it's worth experimenting with the most recent dev version of Rules for Drupal 8 (to build a similar rule).

Note: if you're looking for something like "URL param with a certain value" (as in your own answer), you might also want to consider the Rules URL argument module. Refer to my answer to "How to make the Rules module perform a redirect to an URL that includes a query string?" for more details on that.

Answer 5

The only solution I see is use an external layer like Varnish or Nginx that comes before Drupal. This layer can check for a magic key (URL param with a certain value, a cookie or a custom header). If magic key is present, the external layer removes the magic key and delivers request to the back end, that's Drupal. If magic key is not present this external layer should return 403.

This external layer can check for IP, range or whatever methods to also easy the dev life.

A diagram:

This way:

• Site is absolutely private unless you have the magic key, no site info is leaked.
• No Authorization header conflict.
• Can be bypassed easily adding the cookie, URL param or header on the client. For non technical users the URL param should be used. In this case the external layer could also add a cookie with the magic key when this param is detected. So next requests pass through thanks of this added cookie.
• Transparent for Drupal: Drupal never knows.

Drawbacks:

• You have to setup the external layer.
• You have to supply a magic key on the requests. This can be cumbersome for non technical clients.

Answer 6

Drupal 8 basic_auth module cannot be combined with other Basic Auth solutions. Check this core issue. The Shield module copes witht the question like this.

Answer 7

Time has passed and now I've found a simpler approach: use Shield module

PHP Authentication shield. It creates a simple shield for the site with Apache authentication. It hides the sites, if the user does not know a simple username/password. It handles Drupal as a "walled garden". This module helps you to protect your (dev) site with HTTP authentication.

Its configuration allows to whitelist certain paths. REST paths can be whitelisted because they already have their own authentication mechanism. It works with Apache or any other web server.

Note that the whitelist functionality is only available as a patch in Drupal 8. UPDATE: Included time ago since 8.x-1.5 release.

Answer 8

Use other method to protect the dev site than Basic Auth.

Trying to keep thins as simple as possible, you may take advantage of the Drupal user permission setting. In your case, create roles you need (maybe developer, tester, themer, etc ) and give them access to content as per your needs. Once done, give no access to anonymous users. This can be done by a few lines of custom code or contrib modules (example https://www.drupal.org/project/content_access )

Thanks for your feedback