I'm trying to figure out the best way to setup a staging environment with some access restrictions.
The simple solution would be to throw up Basic Authentication, but then I won't be able to point Google Page Speed Insights at it while testing performance optimizations, as well as other similar external services that I want to access it.
Could make it completely public with robots.txt in order to prevent it from showing up in search engines. But my concern there is that the risk of any mistake in the robots.txt is fairly high, and I'd rather not have to worry about that.
If you don't block search engines (or if some ignore it), then you'll be getting live customers placing orders to your staging site, which won't make them happy.
Or even worse, if you accidentally deploy the robots.txt to production, you'll lose all your Google juice and a good chunk of sales.
So the option that I'm liking is a simple IP address restriction. But I'd love to be able to add/remove restrictions without having to restart Nginx, just to again minimize risk while making changes.
So I'm beginning to lean towards a quick module that, when enabled, will look at developer IP addresses and only allow access to the site (front and backend) if the user's IP address (or X_FORWARDED_FOR) match it.
Wondering if this sounds like a reasonable solution or if there's something simpler that I'm missing.
UPDATE: Given that the robots.txt can be controlled via a native backend switch and the demo store notice will prevent any legitimate customer orders, and since I'm really not concerned about public access to the staging site, I like Phil's solution.
But for anyone that does want to restrict access to their staging site, I think Kris's solution is the way to go.
UPDATE 2: Not 100% sure what the robots.txt options are supposed to do in System Config > Design > HTML Head, but in my case – and from a brief search this appears to be common – I just have a flat robots.txt text file in place that's being used, so that config option isn't being respected.
So I'm going with the maintenance module for now:
https://github.com/aleron75/Webgriffe_Maintenance
Best Answer
A few suggestions - some are built-in!
- Developer IP restriction is built-in in System Config > Developer:This doesn't restrict IP access. Move along.
IP restriction is tough and I prefer to handle this at the firewall, personally. IP tables is also a candidate, as is htaccess restriction or via
$_SERVER['REMOTE_ADDR']in index.php.Update the default per-page robots meta in the CMS to NOINDEX/NOFOLLOW while in staging in System Config > Design > HTML Head: