7

Мы используем следующую функцию для автоматического обнаружения, если мы на машине внутри или на живом сервере, а затем выбрать соответствующие конфиги для различных компонентов:Автоопред внутренняя/внешняя среда разработки

function devIsLocal(){ 

    $res=false; 

    $http_host=$_SERVER['HTTP_HOST']; 

    if($http_host=='localhost')$res=true; 
    if($http_host=='127.0.0.1')$res=true; 
    if(substr($http_host,-4)=='.lan')$res=true; 
    if(strpos($http_host, '.')===false)$res=true; 

    return($res); 

} 

Как вы можете см. это зависит только от значения HTTP_HOST.

Конечно, если вы используете какой-то виртуальный хост локально, например example.com, тогда функция будет обманута.

Есть ли другие способы обмануть функцию? и какие другие переменные/места мы могли бы заглянуть, чтобы определить, где мы находимся?

ответ

10
'127.0.0.1' == $_SERVER["REMOTE_ADDR"] 

Это будет никогда не оценивайте как TRUE на вашей живой системе.:)

+2

Он также не будет, если вы получите доступ к локальному серверу с его общедоступным IP-адресом. –

+0

+1 для упоминания проверки IP-адреса. Энди прав, нам также придется добавить диапазоны ip, зарезервированные для интрасетей. Будет ли это работать тогда? – zaf

+0

@zaf: Да, конечно. Энди неправильно понял это как полное решение, а я просто хотел показать общую концепцию. Возможно, мне нужно быть более явным в будущем ...:// – fuxia

1

Создайте, а затем ищите файл, который существует только в файловой системе live сервера.

Предоставлено, ваши условия должны быть как можно более похожими; я предлагаю что-то вроде этого: в каталоге/var/environment/есть файл с именем {devel | test | qa | staging | live}, в зависимости от сервера, на котором вы находитесь, - тогда просто проверьте имя файла.

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

+0

Это еще один авеню. Вместо того, чтобы создавать файл (а затем помнить об этом), я думал о проверке файловой системы для подсказок, например, в домашних каталогах и т. Д., Но иногда файловая система производственных серверов идентична серверу тестирования. – zaf

+0

Действительно. Я хотел создать/var/environment/devel в devel,/var/environment/live on live и т. Д. Этим файлам не нужно иметь никакого контента, и они не должны использоваться ни для чего, кроме различия в среде. Отредактировал свой ответ, чтобы уточнить. – Piskvor

+0

Вот как я пошел с моим самым последним проектом. Я просто создал файл под названием development.txt и искал его в файле config.php. Он прост, явный и не требует изменений вне каталога проекта. –

0

Конечно, если вы используете виртуальный хост локально, например example.com, тогда функция будет обманута.

Также, если хост не является локальным, но использует widlcard или default vhost defn, и пользователь добавляет IP-адрес в файл hosts локально.

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

function getEnv(){ 
    return 'Live'; 
} 

или

function getEnv(){ 
    return 'Test'; 
} 

Если оба envs находятся на тот же сервер - вы все равно можете это сделать, установив include_path в конфигурацию Apache или .htaccess.

Это также позволяет отделить потенциально чувствительные специфические данные env - например, хосты базы данных/пароли и ключи доступа.

C.

+0

Мы могли бы просто проверить, существует ли каталог, например домашний каталог какого-либо пользователя. Интересная идея. Но иногда выделение файловой системы выделенных производственных серверов отражает внутренний сервер тестирования. – zaf

15

Установите переменную окружения в настройке виртуального хоста Apache. Это делает Zend Framework.

Смотрите ZF quick start guide для примера (раздел "Создание виртуального хоста".)

В вашем httpd.conf или .htaccess файл, говоря:

SetEnv APPLICATION_ENV "development" 

Тогда в вашем приложении, использовать функцию getenv, чтобы получить значение:

$environment = getenv("APPLICATION_ENV"); 
if ($environment == "development") 
{ 
    // do development stuff 
} 
else if ($environment == "live") 
{ 
    // do live stuff 
} 
+0

+1 для надежности. Я добавил дополнительные параметры в свой ответ – Cez

+0

Иногда редактирование httpd.conf не разрешено. Наличие файла .htaccess, содержащего значение ключа для обозначения среды, не является автоматическим. – zaf

+0

@zaf - можете ли вы рассказать о «наличии файла .htaccess, который содержит значение ключа для обозначения среды, не является автоматическим»? Я лично считаю, что это самое элегантное решение, но хосты могут ограничить то, что вы можете сделать в файле .htaccess - это то, что вы имеете в виду? –

3

Добавление к Andy Shellam's answer ..

При использовании mod_vhost_alias, или иметь различные домены с одной и тем же (виртуальным) корнем документа, вы можете установить переменные зависят от параметров, например

SetEnvIf SERVER_ADDR x.x.x.x APPLICATION_ENV=development 
SetEnvIf HTTP_HOST abc.example.com APPLICATION_ENV=development 
+0

Не использует ли 'SetEnvIf' регулярное выражение для вычисления условия if? Если это так, вам нужно будет избежать '.', не так ли? –

+0

@ Lèsemajesté Допустимо, документация показывает экранированные периоды, но кажется, что она отлично работает в любом случае, когда я использовал SetEnvIf – Cez

+0

. Я полагаю, что это имеет смысл, так как '.' будет соответствовать любому символу, включая период, и потому, что IP-адреса следуют фиксированный формат, это не вызовет никаких других проблем в этом случае. –