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

Найпростішим рішенням було б підняти базову автентифікацію, але тоді я не зможу вказувати на неї 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 текстовий файл на місці, яке використовується, так що параметр config не дотримується.

Тому я зараз переходжу з модулем технічного обслуговування: https://github.com/aleron75/Webgriffe_Maintenance

Кілька пропозицій - деякі вбудовані!

- обмеження для розробника вбудоване в 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

Є кілька різних способів зробити це.

Одним із способів було б змусити ваших розробників редагувати свій / хост-файл із правильною IP-адресою.

Існує розширення, яке вимагає зробити це більш елегантно: http://www.magentocommerce.com/magento-connect/et-ip-security.html

Оскільки ви запитали про Varnish в коментарях, я збираюся поділитися моєю конфігурацією з HTTP Basic Authentication за допомогою 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);
}
}