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

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

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

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

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

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

ОТВЕТЫ

Ответ 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

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

Ответ 2

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

Ответ 3

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

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

Я также обычно ставил такую ​​директиву: SetEnv APP_ENV production

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

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

Ответ 4

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

  • htaccess.dev
  • htaccess.live

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

@formicin,

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

Если логика должна быть реализована в коде (а не через конфигурацию 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.
}

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

Прокомментируйте, если я пропустил отметку, или если вы хотите уточнить, как обращаться с логином.

Спасибо!

Ответ 8

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

на dev.example.com: permission.php

<?PHP
   // Do a password check
?>

на www.example.com: permission.php

<?PHP
   // Just an empty file
?>

на сайте dev он будет делать то, что нужно сделать для passwording, но на реальном сайте он ничего не сделает.

Ответ 9

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

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

... ИЛИ...

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