I always setup a .htpasswd to password protect my entire dev and staging sites so that they cannot be visited by search engines and unwanted human visitors.

I usually do this through my hosting companies Control Panels, although I know it can also be done directly.

But how should I do this with my BOA system? (I assume BOA stands for Barracuda Octopus Aegir.)

I believe there is drupal module that can do this too, but seems like there should be a way to do it all dev and staging sites in similar fashion that cacheing is turned of for properly named sub-domain dev sites.

Thanks for your help in advance!! I'll post back to if I figure out a solution on my own.
Steve

P.S. I didn't know whether to mark this post as a documentation/support request or something else. Hopefully, it's close.

Comments

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

There is no .htaccess in the Nginx world, so you would need to modify (by hand) vhost files, which is not an option (IMO).

We already deny access to any site with "dev" in the domain for known spiders/robots, see: http://drupalcode.org/project/octopus.git/blob/HEAD:/aegir/conf/global.i...

But to protect the sites better, you will have to enable (bundled) securesite module (but it works only for D6 core platforms) or put the site in the offline mode.

wickwood’s picture

wickwood CreditAttribution: wickwood commented

Thanks again Omega8cc for the quick and complete helpful response. I have a lot to learn here because I'm a total newb to Nginx.

The securesite module is what I found too and was hoping there was a more efficient way to protect all of my dev sites I also don't ant to put the site in offline-mode because then my clients can't see their sites in dev and I can't test things as an anonymous user.

Steve

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Status: Active » Closed (works as designed)
juan_g’s picture

juan_g CreditAttribution: juan_g commented

I installed and tried the Secure Site module.

Secure site's README.txt says: "If you are using HTTP Auth and are unable to login, PHP could be running in CGI mode."
http://drupalcode.org/project/securesite.git/blob_plain/HEAD:/README.txt

In Drupal, Administration > Reports > Status report > PHP > more information:

Server API: FPM/FastCGI

And with a configuration mistake for HTTP digest "you may lock yourself out of your own site."

So I used only "HTML log-in form", more reliable than HTTP.

It seemed to work well. However, looking at:

Administration > Reports > Status report

securesite had created problems for the Advanced CSS/JS Aggregation module:

Adv CSS/JS Agg - HTTP Request
HTTP requests to advagg for js files are not getting through.

AdvAgg will issue a request for a file that does not exist inside of the AdvAgg directory. If AdvAgg sends a 404, everything is ok; if something else sends a 404 then that means that AdvAgg will not be able to generate an aggregate if it is missing as something else is handling the 404 before AdvAgg has a chance to do it. If you are reading this, it means that something else is handling the 404 before AdvAgg can. Raw request info:

(...)

<head>
<title></title>
<link type="text/css" rel="stylesheet" media="all" href="/sites/all/modules/securesite/theme/securesite.css" />
</head>
<body>

(...)

Therefore, I disabled and uninstalled securesite, not compatible with AdvAgg, and will have the non-live sites normally in maintenance mode:

Administration > Configuration > Development > Maintenance mode > + Add to Default shortcuts

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

PHP-FPM is not that (old) CGI mode it warns about, so HTTP Auth works perfectly well.

Also, you are never locked out, since you can always disable the module with Drush if you have made any mistake.

juan_g’s picture

juan_g CreditAttribution: juan_g commented

Thanks. According to Drush.org that would be "pm-disable":

drush pm-disable securesite

or its alias "dis":

drush dis securesite
juan_g’s picture

juan_g CreditAttribution: juan_g commented

Or for a specific site in multisite:

drush -l http://example.com/ pm-disable module_name
juan_g’s picture

juan_g CreditAttribution: juan_g commented

I've just tried Secure Site again, this time with the default "HTTP basic" authentication type instead of "HTML log-in form", but it's still not compatible with Advanced CSS/JS Aggregation module, giving the same error in status report.

I think the maintenance mode solution is ok in my case. Thank you.

juan_g’s picture

juan_g CreditAttribution: juan_g commented

Of course Advanced CSS/JS Aggregation is only meant for live production sites, and not needed for very low traffic dev sites, however now I wanted to test everything. Probably securesite can be ok to hide most dev sites.