Próbuję znaleźć najlepszy sposób skonfigurowania środowiska testowego z pewnymi ograniczeniami dostępu.

Prostym rozwiązaniem byłoby podniesienie podstawowego uwierzytelnienia, ale wtedy nie będę w stanie wskazać na to Google Page Speed ​​Insights podczas testowania optymalizacji wydajności, a także innych podobnych usług zewnętrznych, do których chcę uzyskać dostęp.

Może uczynić go całkowicie publicznym w pliku robots.txt, aby zapobiec pojawianiu się go w wyszukiwarkach. Obawiam się jednak, że ryzyko błędu w pliku robots.txt jest dość wysokie i wolałbym się tym nie przejmować.

Jeśli nie zablokujesz wyszukiwarek (lub jeśli niektórzy go zignorują), będziesz pozyskiwał klientów na żywo do składania zamówień na swojej stronie pośredniej, co ich nie uszczęśliwi.

Albo jeszcze gorzej, jeśli przypadkowo wdrożysz plik robots.txt do produkcji, stracisz cały sok z Google i sporą część sprzedaży.

Tak więc opcja, która mi się podoba, to proste ograniczenie adresu IP. Chciałbym jednak móc dodawać / usuwać ograniczenia bez konieczności ponownego uruchamiania Nginx, aby ponownie zminimalizować ryzyko podczas wprowadzania zmian.

Zaczynam więc skłaniać się ku szybkiemu modułowi, który po włączeniu będzie sprawdzał adresy IP deweloperów i zezwoli na dostęp do strony (front i backend) tylko wtedy, gdy adres IP użytkownika (lub X_FORWARDED_FOR) będzie zgodny.

Zastanawiam się, czy to brzmi jak rozsądne rozwiązanie, czy też brakuje mi czegoś prostszego.

AKTUALIZACJA: Biorąc pod uwagę, że plik robots.txt może być kontrolowany za pomocą natywnego przełącznika zaplecza, a powiadomienie ze sklepu demo zapobiegnie wszelkim uzasadnionym zamówieniom klientów, a ponieważ naprawdę nie martwię się o publiczny dostęp do strony pośredniej, podoba mi się rozwiązanie Phila.

Ale dla każdego, kto chce ograniczyć dostęp do swojej witryny inscenizacyjnej, myślę, że rozwiązaniem jest Kris.

AKTUALIZACJA 2: Nie jestem w 100% pewien, co mają zrobić opcje robots.txt w Konfiguracja systemu> Projekt> Głowica HTML, ale w moim przypadku - i po krótkim wyszukiwaniu wydaje się to powszechne - mam po prostu płaski plik robots.txt używany plik tekstowy, więc opcja konfiguracji nie jest przestrzegana.

Więc na razie idę z modułem konserwacji: https://github.com/aleron75/Webgriffe_Maintenance

Kilka sugestii - niektóre są wbudowane!

- Ograniczenie własności intelektualnej programisty jest wbudowane w Konfiguracja systemu> Deweloper:

Nie ogranicza to dostępu do adresu IP. Poruszać się.

• Ograniczenia IP są trudne i wolę sobie z tym poradzić osobiście. Tabele IP są również kandydatami, podobnie jak ograniczenie htaccess lub via $_SERVER['REMOTE_ADDR']in index.php.

• Zaktualizuj domyślną metę robotów na stronę w CMS do NOINDEX / NOFOLLOW podczas przemieszczania w Konfiguracja systemu> Projekt> Nagłówek HTML:

• W tym samym obszarze konfiguracji można wyświetlić powiadomienie ze sklepu demonstracyjnego :

Naszym podstawowym sposobem blokowania (większości) środowisk pomostowych jest uwierzytelnianie BASIC. Ale mamy również środki zapobiegawcze, aby zapobiec ich wykryciu przez silniki, blokując link pojawiający się na publicznej stronie internetowej (to nigdy się nie zdarza), a także aby zapobiec ich indeksowaniu przez Google.

Skonfigurowałem regułę /etc/httpd/conf.d/robots.confz następującym aliasem:

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

Alias ​​kieruje wszystkie żądania do lokalizacji robots.txt do pliku zablokowanego. Oznacza to, że nie ma znaczenia, co znajduje się w pliku robots.txt w katalogu głównym pomostowego Magento, serwer zawsze będzie obsługiwał następujące reguły:

User-agent: *
Disallow: /

Lokalizacja i spełnianie dowolnych umożliwia podawanie pliku robots.txt każdemu, niezależnie od uwierzytelnienia, ponieważ nie mamy globalnych disallow from anyreguł.

W przypadku uwierzytelniania za pomocą hasła mam skonfigurowane reguły, dzięki którym mogę tymczasowo otworzyć uwierzytelnianie w jednej witrynie, dodając Satisfy anydo .htaccesspliku. Wynika to z faktu, że prowadzimy witryny wielostopniowe na tym samym dedykowanym wewnętrznym serwerze pomostowym. Pozwoli to również na ustawienie allow fromreguł wraz z Satisfy anyusunięciem uwierzytelnienia hasła na określone adresy IP, zachowując je dla wszystkich innych (jeśli naprawdę muszę).

Powodem, dla którego nie lubię białej listy opartej na IP (tj. Bez uwierzytelniania opartego na hasłach), jest to, że adresy IP klienta nie zawsze są statyczne. Co oznacza, że ​​będziemy musieli zaktualizować ich adresy IP, aby uzyskać dostęp (potencjalnie) codziennie lub co tydzień, w zależności od tego, jak długo ich dostawcy DHCP dzierżawią DHCP.

W przypadku DNS używamy symboli wieloznacznych DNS, aby roboty indeksujące DNS nie odbierały wszystkich nazw hostów witryny, które muszą mieć publiczny DNS. Google faktycznie pobierze witrynę z rekordów DNS. Zapobiega to temu, co oznacza, że ​​jedynym sposobem na znalezienie go jest pozostawienie gdzieś linku. Ale zmuszenie pliku robotów do podania reguły „zabroń” zatrzyma ich indeksowanie, jeśli znajdą link.

Gdybym był w miejscu handlowca prowadzącego witrynę sceniczną dla witryny firmowej, zrobiłbym coś nieco inaczej i po prostu zablokowałbym cały ruch przychodzący do sceny, chyba że pojawią się znane adresy IP. Każdy, kto pracuje na stronie zdalnie (wewnętrznie), będzie musiał połączyć się z firmową siecią VPN, aby uzyskać do niej dostęp, jeśli nie miałby statycznego adresu IP, który mógłbym dodać do białej listy.

Posiadanie publicznego DNS jest koniecznością, jeśli musisz przetestować takie rzeczy, jak integracja procesorów płatności, które, w przeciwieństwie do większości bram, muszą oddzwonić do serwera, aby przejść proces płatności.

Opracowałem moduł umożliwiający tryb konserwacji, którego można używać z takim samym skutkiem, jak blokowanie użytkownikom dostępu do frontu (nie administratora, który można ograniczyć za pomocą natywnej funkcji blokowania IP Magento).

Możesz infact pozwolić niektórym adresom IP na dostęp do frontendu nawet przy włączonym trybie konserwacji.

Może możesz spróbować, mając nadzieję, że to pomoże. Jest darmowy i open source: https://github.com/aleron75/Webgriffe_Maintenance

Istnieje kilka różnych sposobów na zrobienie tego.

Jednym ze sposobów byłoby zmuszenie programistów do edycji pliku / hosts z poprawnym adresem IP.

Istnieje rozszerzenie, które twierdzi, że robi to w bardziej elegancki sposób: http://www.magentocommerce.com/magento-connect/et-ip-security.html

Ponieważ w komentarzach zapytałeś o Varnish, podzielę się moją konfiguracją z Podstawowym uwierzytelnianiem HTTP za pomocą Varnish, łącznie z wyjątkami. Musisz to ustawić w VCL, w przeciwnym razie strony w pamięci podręcznej byłyby zawsze dostępne.

Konfiguracja lakieru VCL

Chcę zezwolić na określone adresy IP i zakresy oddzwaniania dostawców płatności i takie, które definiuję jako ACL u góry pliku VCL:

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

Następnie dodaj następujące na końcu vcl_recv, tuż przed return (lookup):

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

paymentto zdefiniowana powyżej ACL. Zezwalam również na dostęp do trasy przesyłania, ponieważ program ładujący Flash nie wysyła nagłówków uwierzytelniania, a zatem nie działa w przypadku uwierzytelniania podstawowego HTTP. Zastąp ADMIN rzeczywistym adresem administracyjnym. W ten sposób możesz dodać dowolne inne wyjątki.

XXXXXXXXX to nazwa użytkownika i hasło zakodowane w standardzie base64. Uruchom następujące polecenie w powłoce, aby wygenerować ten ciąg:

$ echo -n "username:password" | base64

Następnie dodaj to na końcu VCL, aby zdefiniować odpowiedź błędu 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);
}
}