How can I password protect dev but not live while using SVN?

Question

We have this workflow: Development is done on dev.example.com Changes are committed to SVN, then exported to live site. Live site is at www.example.com

I want to password protect dev.example.com, but if I do it with .htaccess, we will be using the same .htaccess at live site and it will get password protected too.

We are using Dreamhost shared hosting, I have SSH access, but I can not edit Apache's configuration .conf files.

We don't want to have separate .htaccess files for dev&live and ignore .htaccess in SVN because updates are done to .htaccess as well.

So what should I do?

Answer 1

If mod_setenvif is enabled on the server, you could add this to your .htaccess file:

SetEnvIfNoCase ^HOST$ .+ unauthenticated
SetEnvIfNoCase ^HOST$ ^dev\.example\.com$ !unauthenticated

AuthType Basic
AuthName "Secured"
AuthUserFile /path/to/.htpasswd
Require valid-user
Order allow,deny
Allow from env=unauthenticated
Satisfy any

What this basically does is it sets an environment variable called "unauthenticated" but unsets it if the HOST (the host requested by the browser) is exactly "dev.example.com". In the Directory directive, the "satisfy any" tell Apache to allow the request if any one of the conditions are met. This means that on "dev.example.com", the environment variable won't be set and as such, you'll be required a password. For any other hosts, the variable will be set so Apache won't ask for credentials.

Answer 2

You could ignore .htaccess, keeping it out of your repository entirely. Then just have two different .htaccess files on each server. Because they're ignored, they won't get overwritten in the SVN update.

Answer 3

Do it in the Apache virtualhost configuration rather than a .htaccess file (which will usually be in /etc/apache or /etc/apache2.)

I put everything that would go into my .htaccess here instead. These settings usually need to differ per-deployment, so it makes sense to keep them outside the repo. It also makes your app a little faster if Apache can load the directives when it starts up, rather than from an .htacess file on every request.

I also usually put a directive like this in there: SetEnv APP_ENV production

Which will get passed through to your app and allow you to detect whether you're in a dev vs. production environment and adjust your settings accordingly.

I also keep a copy of this conf file checked into the assets folder of my repo for easy access.

Answer 4

Put two files in your repository:

• htaccess.dev
• htaccess.live

Make a script which takes take care of the deploy by first doing an export of all files to the target server and then renames the correct htaccess file depending on which server it is exported to. The script should be simple to invoke and to the entire deploy in one step, including handling host names for the server etc:

deploy dev or deploy live are two good command lines to aim at.

For the ssh logon you will either have to prompt the user for the password from the script, or better, use key-based authentication so that logon is automatic.

Answer 5

Instead of developing on a remote server, why not develop on your local machines? You could create branches in your repo for each dev, and merge their changes with the trunk when they're ready to be pushed to the live site.

Answer 6

You should really keep your development and production environments as separated as possible. I would recommend you reevaluate your original desire to use a shared .htaccess file. In my experience, server files like .htaccess typically aren't updated all that often, so it won't pose a risk to productivity.

If you are using virtual hosts, you can put the authorization code in that file (httpd or vhosts configuration file), which will allow you to still use a shared .htaccess file.

Answer 7

@formicin,

I'm assuming that the major goal is to keep prying eyes away from your dev content.

If the logic is to be implemented in the code (and not through Apache configuration), you could use the hostname specified in the HTTP request itself.

$dev_server = "dev.mysite.com";
$hostname_used_to_access_site = $_SERVER['SERVER_NAME'];

if (strcasecmp($hostname_used_to_access_site, $dev_server) == 0) {
    // The server name sent by the browser matches the name
    // of the dev server, so check for a valid session. If
    // the user hasn't already logged in, redirect to a
    // login page.
}

This could be put into a common include file, or at the top of each page. Note that the code would be the same between dev and production, but the value of $_SERVER['SERVER_NAME'] would cause the login code to be executed only on the dev server.

Please comment if I've missed the mark, or if you'd like clarification about how to handle the login.

Thanks!

Answer 8

Do an import in the header of your file to pull in a file include("permission.php")

on dev.example.com: permission.php

<?PHP
   // Do a password check
?>

on www.example.com: permission.php

<?PHP
   // Just an empty file
?>

on the dev site it will do what needs to be done for passwording, but on the live site it will do nothing at all.

Answer 9

Two simple suggestions - neither require .htaccess or server configuration.

1) If you're building on a CMS framework such as Wordpress, you can simply set the privacy settings for the site (dashboard > settings) to be password protected on dev site, and since all those settings are database managed, you can just set the live site to be public.

...OR...

2) Develop locally and push to a separate password protected install.