Как я могу защитить паролем dev, но не жить при использовании SVN?

Question

У нас есть этот рабочий процесс: Разработка ведется на dev.example.com Изменения фиксируются в SVN, а затем экспортируются на действующий сайт. Прямой сайт www.example.com

Я хочу защитить паролем dev.example.com, но если я сделаю это с .htaccess, мы будем использовать тот же .htaccess на живом сайте, и он тоже будет защищен паролем.

Мы используем общий хостинг Dreamhost, у меня есть доступ по SSH, но я не могу редактировать файлы конфигурации Apache .conf.

Мы не хотим иметь отдельные файлы .htaccess для dev & live и игнорируем .htaccess в SVN, поскольку обновления также выполняются для .htaccess.

Так что мне делать?

Answer 1

Если на сервере включен mod_setenvif, вы можете добавить его в файл .htaccess:

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

Что он делает в основном, так это устанавливает переменную среды, называемую «неаутентифицированной», но сбрасывает ее, если HOST (хост, запрошенный браузером) - это точно «dev.example.com». В директиве Directory, «удовлетворить все», Apache разрешает запрос, если выполняется любое из условий. Это означает, что на «dev.example.com» переменная окружения не будет установлена, и вам потребуется пароль. Для любых других хостов будет установлена ​​переменная, поэтому Apache не будет запрашивать учетные данные.

Answer 2

Вы можете игнорировать .htaccess, полностью не допуская его в хранилище. Тогда просто имейте два разных .htaccess файла на каждом сервере. Поскольку они игнорируются, они не будут перезаписаны в обновлении SVN.

Answer 3

Делайте это в конфигурации виртуального хоста Apache, а не в файле .htaccess (который обычно находится в /etc/apache или /etc/apache2.)

Вместо этого я положил сюда все, что войдет в мой .htaccess. Эти параметры обычно должны различаться в зависимости от развертывания, поэтому имеет смысл держать их вне репо. Это также делает ваше приложение немного быстрее, если Apache может загружать директивы при запуске, а не из файла .htacess при каждом запросе.

Я также обычно помещаю туда директиву: SetEnv APP_ENV production

Это будет передано в ваше приложение и позволит вам определить, находитесь ли вы в среде разработки и разработки, и соответствующим образом изменить настройки.

Я также держу копию этого conf-файла в папке ресурсов моего репозитория для быстрого доступа.

Answer 4

Поместите два файла в ваш репозиторий:

• htaccess.dev
• htaccess.live

Создайте скрипт, который позаботится о развертываниисначала выполните экспорт всех файлов на целевой сервер, а затем переименуйте правильный файл htaccess в зависимости от того, на какой сервер он был экспортирован.Сценарий должен быть простым для запуска и всего развертывания за один шаг, включая обработку имен хостов для сервера и т. Д .:

deploy dev или deploy live - это две хорошие командные строки, к которым нужно стремиться.

Для входа в систему через ssh вам нужно будет либо запросить у пользователя пароль из скрипта, либо лучше использовать аутентификацию на основе ключей, чтобы вход происходил автоматически.

Answer 5

@ formicin,

Я предполагаю, что главная цель - не смотреть на контент вашего разработчика.

Если в коде должна быть реализована логикачерез настройку Apache), вы можете использовать имя хоста, указанное в самом HTTP-запросе.

$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.
}

Это может быть помещено в общий включаемый файл или вверху каждой страницы.Обратите внимание, что код будет одинаковым между dev и production, но значение $_SERVER['SERVER_NAME'] приведет к тому, что код входа будет выполняться только на dev-сервере.или если вы хотите получить разъяснения о том, как обрабатывать логин.

Спасибо!

Answer 6

Вы должны по-настоящему держать среду разработки и производства как можно более разделенными. Я бы порекомендовал вам переоценить ваше первоначальное желание использовать общий файл .htaccess. По моему опыту, серверные файлы, такие как .htaccess, как правило, обновляются не так часто, поэтому это не представляет риска для производительности.

Если вы используете виртуальные хосты, вы можете поместить код авторизации в этот файл (файл конфигурации httpd или vhosts), который позволит вам по-прежнему использовать общий файл .htaccess.

Answer 7

Вместо разработки на удаленном сервере, почему бы не разработать на своих локальных машинах? Вы можете создавать ветви в своем репо для каждого разработчика и объединять их изменения со стволом, когда они будут готовы к отправке на действующий сайт.

Answer 8

Выполните импорт в заголовок вашего файла, чтобы получить файл include("permission.php")

на dev.example.com: permission.php

<?PHP
   // Do a password check
?>

на www.example.com: permission.php

<?PHP
   // Just an empty file
?>

на сайте разработчика он будет делать то, что нужно сделать для написания пароля, но на живом сайте он вообще ничего не сделает.

Answer 9

Два простых предложения - ни один не требует .htaccess или настройки сервера.

1) Если вы строите на платформе CMS, такой как Wordpress, вы можете просто установить параметры конфиденциальности для сайта (панель инструментов> настройки), чтобы они были защищены паролем на сайте разработчика, и так как все эти параметры управляются базой данных, Вы можете просто сделать живой сайт общедоступным.

... ИЛИ ...

2) Разработка локально и установка отдельной защищенной паролем установки.