Я пытаюсь найти лучший способ настроить промежуточную среду с некоторыми ограничениями доступа.

Простым решением было бы отключить обычную аутентификацию, но тогда я не смогу указать на Google Page Speed ​​Insights при тестировании оптимизации производительности, а также на другие подобные внешние службы, к которым я хочу получить доступ.

Может сделать его полностью открытым с robots.txt, чтобы он не появлялся в поисковых системах. Но меня беспокоит то, что риск любой ошибки в файле robots.txt достаточно высок, и мне не стоит об этом беспокоиться.

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

Или, что еще хуже, если вы случайно развернете robots.txt в рабочей среде, вы потеряете весь свой сок Google и большую часть продаж.

Так что вариант, который мне нравится, это простое ограничение IP-адреса. Но я бы хотел иметь возможность добавлять / снимать ограничения без перезапуска Nginx, просто чтобы снова минимизировать риск при внесении изменений.

Поэтому я начинаю склоняться к быстрому модулю, который при включении будет смотреть на IP-адреса разработчика и разрешать доступ к сайту (передний и внутренний), только если IP-адрес пользователя (или X_FORWARDED_FOR) совпадает с ним.

Интересно, звучит ли это как разумное решение или есть что-то более простое, что я пропускаю.

ОБНОВЛЕНИЕ: Учитывая, что robots.txt можно контролировать с помощью встроенного переключателя бэкэнда, и уведомление о демонстрационном магазине предотвратит любые законные заказы клиентов, и, поскольку я действительно не обеспокоен публичным доступом к промежуточному сайту, мне нравится решение Фила.

Но для любого, кто хочет ограничить доступ к своему промежуточному сайту, я думаю, что решение Криса - путь.

ОБНОВЛЕНИЕ 2: Не уверен на 100%, что опции robots.txt должны делать в System Config> Design> HTML Head, но в моем случае - и из краткого поиска это кажется распространенным - у меня просто плоский robots.txt текстовый файл, который используется, поэтому параметр конфигурации не учитывается.

Итак, сейчас я собираюсь использовать модуль обслуживания: https://github.com/aleron75/Webgriffe_Maintenance

Несколько предложений - некоторые встроены!

- Ограничение IP -адреса разработчика встроено в System Config> Developer:

Это не ограничивает IP-доступ. Двигайся.

• Ограничение IP является жестким, и я предпочитаю обращаться с этим лично на брандмауэре. IP-таблицы также являются кандидатами, как ограничение htaccess или через $_SERVER['REMOTE_ADDR']в index.php.

• Обновите метаданные роботов для каждой страницы в CMS по умолчанию на NOINDEX / NOFOLLOW, пока они находятся в стадии настройки в System Config> Design> HTML Head:

• В той же области конфигурации есть возможность отображения уведомления о демонстрационном магазине :

Нашим основным средством блокировки (большинства) промежуточных сред является BASIC-аутентификация. Но у нас также есть превентивные меры, чтобы предотвратить их обнаружение движками, запретить показ ссылки на общедоступном веб-сайте (этого никогда не происходит), а также предотвратить их индексацию Google.

Я настроил правило /etc/httpd/conf.d/robots.confсо следующим псевдонимом:

Alias /robots.txt /<path_to_public_html>/robots.txt
<Location /robots.txt>
  Satisfy any
</Location>

Псевдоним направляет все запросы в расположение файла robots.txt в заблокированный файл. Это означает, что не имеет значения, что находится в файле robots.txt в промежуточном корне Magento, сервер всегда будет выполнять следующие правила:

User-agent: *
Disallow: /

Расположение и соответствие любому разрешает доступ к файлу robots.txt кому угодно, независимо от аутентификации, поскольку у нас нет глобальных disallow from anyправил.

Для аутентификации по паролю у меня есть настроенные правила, чтобы я мог временно открыть аутентификацию на одном сайте, добавив Satisfy anyв .htaccessфайл. Это потому, что мы запускаем многоэтапные сайты на одном выделенном внутреннем промежуточном сервере. Это также позволит устанавливать allow fromправила наряду с Satisfy anyудалением аутентификации по паролю для определенных IP-адресов, сохраняя ее для всех остальных (если мне действительно нужно).

Причина, по которой мне не нравится белый список на основе IP (то есть без аутентификации на основе пароля), заключается в том, что IP-адреса клиента не всегда являются статическими. Это означает, что тогда мы должны будем обновить их IP-адреса, чтобы получить доступ к ним (потенциально) ежедневно или еженедельно в зависимости от того, как долго их провайдеры DHCP удерживают аренду.

Для DNS мы используем подстановочный DNS, так что сканеры DNS не будут получать все имена хостов сайта этапа, которые должны иметь общедоступный DNS. Google фактически подберет сайт из DNS-записей. Это предотвращает это, означая, что единственный способ для них найти это, если кто-то оставляет ссылку, лежащую где-то. Но если заставить файл роботов обслуживать правило запрета, они не будут индексировать его, если найдут ссылку.

Если бы я был на месте продавца, управляющего сценическим сайтом для веб-сайта компании, я бы поступил немного иначе и просто заблокировал бы весь трафик, поступающий на сценический бокс, если бы не приходили известные IP-адреса. Любой, кто работает на сайте удаленно (внутри компании), должен был бы подключиться к корпоративной сети VPN для доступа, если у них нет статического IP-адреса, который я мог бы внести в белый список.

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

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

Вы можете разрешить доступ к веб-интерфейсу некоторым IP-адресам даже при включенном режиме обслуживания.

Может быть, вы можете попробовать, надеясь, что это поможет. Это бесплатно и с открытым исходным кодом: https://github.com/aleron75/Webgriffe_Maintenance

Есть несколько разных способов сделать это.

Один из способов - заставить ваших разработчиков редактировать свой файл / hosts с правильным IP-адресом.

Существует расширение, которое утверждает, что делает это более элегантным способом: http://www.magentocommerce.com/magento-connect/et-ip-security.html

Поскольку вы спрашивали о Varnish в комментариях, я собираюсь поделиться своей конфигурацией с базовой аутентификацией HTTP с использованием Varnish, включая исключения. Вы должны настроить его в VCL, иначе кэшированные страницы будут всегда доступны.

Конфигурация лака VCL

Я хочу разрешить определенные IP-адреса и диапазоны для обратных вызовов поставщиков платежей и тому подобное, которые я определяю как ACL в верхней части файла VCL:

acl payment {
  "1.2.3.4"/28;
  "1.3.3.7";
}

Затем добавьте следующее в конце vcl_recv, непосредственно перед return (lookup):

if (! req.http.Authorization ~ "Basic XXXXXXXXX"
&& ! client.ip ~ payment
&& ! req.url ~ "^/index.php/ADMIN/.*/upload") {
    error 401 "Restricted";
}

paymentэто ACL, определенный выше. Я также разрешаю доступ к маршруту загрузки, потому что загрузчик Flash не отправляет заголовки аутентификации и, следовательно, не выполняет HTTP Basic Auth. Замените ADMIN фактическим URL администратора. Таким способом вы можете добавить любые другие исключения.

XXXXXXXXX - это имя пользователя и пароль в кодировке base64. Запустите следующее в оболочке, чтобы сгенерировать эту строку:

$ echo -n "username:password" | base64

Затем добавьте это в конце VCL, чтобы определить реакцию на ошибку 401:

sub vcl_error {
if (obj.status == 401) {
  set obj.http.Content-Type = "text/html; charset=utf-8";
  set obj.http.WWW-Authenticate = "Basic realm=Secured";
  synthetic {" 

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
 "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">

 <HTML>
 <HEAD>
 <TITLE>Error</TITLE>
 <META HTTP-EQUIV='Content-Type' CONTENT='text/html;'>
 </HEAD>
 <BODY><H1>401 Unauthorized (varnish)</H1></BODY>
 </HTML>
 "};
  return (deliver);
}
}