6

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

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.

5
  • This answer only protects the site from web crawlers that honor robots.txt. Anyone that manages to know the site address can browse the dev site. So, there is no protection of the site for unauthorized visitors because there's no authorization mechanism at all.
    – sanzante
    Feb 24 '16 at 8:09
  • "This answer only protects the site from web crawlers that honor robots.txt" <--- erm... not true. If you look at the first and second articles of the answer and create an index.html file accordingly, that index.html will greet your visitors, not Drupal. Then your clients can access the real website by browsing to index.php. Once you are done with development, you can revert the changes to have made.
    – Kartagis
    Feb 24 '16 at 8:30
  • Yes, that's true, I didn't understand you correctly, sorry. Anyway this hack protects the homepage, but any internal URL will be processed by index.php (given the .htaccess rules that if no file is found the condition "RewriteRule ^ index.php [L]" is used). Or jus trying the index.php.
    – sanzante
    Feb 24 '16 at 11:39
  • So, do you agree with me or not? I can't tell from you comment.
    – Kartagis
    Feb 24 '16 at 12:20
  • 1
    I agree is more than using robots.txt but I don't think is the right answer to the question because site is still accesible if you provide more than the domain. In some way is a security through obscurity solution and that's no acceptable, sorry.
    – sanzante
    Feb 24 '16 at 12:26
0

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

1
  • 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.
    – sanzante
    Feb 21 '16 at 18:12
0

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?

5
  • @tunic adjusted my answer, forgot this was for drupal 8.
    – No Sssweat
    Mar 1 '16 at 22:13
  • I still don't see this kind of approach. Maintenance page is visible, usually with company or organization logo (it can't be a blank page). Any plain file is accesible by URL (maintenance is only processed during a Drupal bootstrap).
    – sanzante
    Mar 2 '16 at 16:42
  • Maintenance page is visible, usually with company or organization logo it can't be a blank page why not? I just told you how to make it a blank page. Did you even read my answer?
    – No Sssweat
    Mar 2 '16 at 21:08
  • Yes, I readed it. What I mean with "it can't be a blank page" is that a complete site must have a real maintenance page for visitors to get info about the status of the site. May be it's better to say 'it must not be a blank page'.
    – sanzante
    Mar 3 '16 at 16:21
  • @tunic, then just remove the {{ logo }} part only, when you go to the put site on maintenance page settings, there is a text box where you can type stuff in it. OR you can just type what ever you want to your maintenance-page.html.twig
    – No Sssweat
    Mar 3 '16 at 22:34
0

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.

5
  • Rules does not work well enough for Drupal 8 to do this yet.
    – Kevin
    Mar 1 '16 at 18:12
  • I'd like to avoid modify Drupal behavior. Also, the iste should work for visitors that use an anoynomus and/or registered user, but only for authorized users.
    – sanzante
    Mar 2 '16 at 16:52
  • I think the Rules Conditions I suggested would already be OK for anonymous users (or pretty easy to refine to meet your exact requirements). And for "registered" users versus "authorized" users you might also further refine this to fit your exact requirements. Possibly you could further enhance it by adding the FLAG module to indicate "authorized". If you could better explain the variations you're looking for, I'd be happy to further tune my answer for it afterwards also, ok? Mar 2 '16 at 16:57
  • Your solution implies to modify the site, adding Rules that may interfer with normal operation of site. In the produciton site the those Rules should be deactivated or configured to not fire. So you have a dev/pre site with a different configuration than production site, so you are not testing (automatically or manually) the same site behavior.
    – sanzante
    Mar 3 '16 at 16:19
  • Thank you for your extra feedback. But to be honest, your comment here includes "new" specs that were not at all included in your question. E.g. your question does not contain the string "prod". Sure I understand your point about using Rules, but I find it hard to believe that that would be the very only difference between your dev/pre versus prod site. I can also think of quite some extra Rules refinements that would probably address your points here also. Maybe you should post a new question related to your prior comment? Mar 3 '16 at 16:40
0

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: enter image description here

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

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.

0

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.

-1

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

2
  • This answer doesn't resolve the proposed issue. The point is to protect a site without modifying its behavior. Proposed solution implies add roles and change permissions on anonymous users, what changes functionality the site. Also, info about the site is leaked as anonympus user can at least see the access denied page, that would have logo of site.
    – sanzante
    Feb 28 '16 at 13:28
  • I can't read those requirement anywhere in your question, @tunic. If you're not happy with my solution, go for something which better matches your requirement. Could flexibility help you. Good luck!
    – augusto
    Feb 28 '16 at 20:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.