Ich versuche herauszufinden, wie eine Staging-Umgebung mit einigen Zugriffsbeschränkungen am besten eingerichtet werden kann.

Die einfache Lösung wäre, die Standardauthentifizierung zu aktivieren, aber dann kann ich nicht auf Google Page Speed ​​Insights verweisen, während ich Leistungsoptimierungen sowie andere ähnliche externe Dienste teste, auf die ich zugreifen möchte.

Könnte es mit robots.txt vollständig veröffentlichen, um zu verhindern, dass es in Suchmaschinen angezeigt wird. Aber ich befürchte, dass das Risiko eines Fehlers in der robots.txt ziemlich hoch ist, und ich würde mir lieber keine Sorgen machen müssen.

Wenn Sie Suchmaschinen nicht blockieren (oder einige davon ignorieren), werden Sie dazu gebracht, dass Live-Kunden Bestellungen auf Ihre Staging-Site aufgeben, die sie nicht glücklich machen.

Schlimmer noch: Wenn Sie die robots.txt versehentlich für die Produktion bereitstellen, verlieren Sie Ihren gesamten Google-Saft und einen guten Umsatz.

Die Option, die mir gefällt, ist eine einfache Einschränkung der IP-Adresse. Aber ich würde gerne Einschränkungen hinzufügen / entfernen können, ohne Nginx neu starten zu müssen, nur um das Risiko beim Vornehmen von Änderungen erneut zu minimieren.

Daher neige ich zu einem schnellen Modul, das, wenn es aktiviert ist, die Entwickler-IP-Adressen überprüft und den Zugriff auf die Site (Frontend und Backend) nur zulässt, wenn die IP-Adresse des Benutzers (oder X_FORWARDED_FOR) mit dieser übereinstimmt.

Ich frage mich, ob dies nach einer vernünftigen Lösung klingt oder ob mir etwas Einfacheres fehlt.

UPDATE: Angesichts der Tatsache, dass die robots.txt-Datei über einen systemeigenen Backend-Schalter gesteuert werden kann und der Hinweis auf den Demo-Store keine legitimen Kundenbestellungen zulässt, mag ich die Lösung von Phil.

Aber für alle, die den Zugriff auf ihre Staging-Site einschränken möchten, ist die Lösung von Kris der richtige Weg.

UPDATE 2: Nicht 100% sicher, was die robots.txt-Optionen in System Config> Design> HTML Head tun sollen, aber in meinem Fall - und nach einer kurzen Suche scheint dies üblich zu sein - habe ich nur eine flache robots.txt Textdatei an Ort und Stelle, die verwendet wird, sodass die Konfigurationsoption nicht beachtet wird.

Also gehe ich jetzt zum Wartungsmodul: https://github.com/aleron75/Webgriffe_Maintenance

Ein paar Vorschläge - einige sind eingebaut!

- Die IP-Beschränkung für Entwickler ist in System Config> Developer integriert:

Dies schränkt den IP-Zugriff nicht ein. Weiter machen.

• Die IP-Beschränkung ist streng und ich ziehe es vor, dies persönlich an der Firewall zu erledigen. IP-Tabellen sind ebenso ein Kandidat wie die Zugriffsbeschränkung oder via $_SERVER['REMOTE_ADDR']in index.php.

• Aktualisieren Sie das Standard-Per-Page-Robots-Meta im CMS auf NOINDEX / NOFOLLOW, während Sie in System Config> Design> HTML Head bereitstellen:

• Im selben Konfigurationsbereich können Sie einen Demo-Store-Hinweis anzeigen :

Unsere Hauptmethode zum Sperren (der meisten) Staging-Umgebungen ist die BASIC-Authentifizierung. Wir haben jedoch auch vorbeugende Maßnahmen ergriffen, um zu verhindern, dass sie von Suchmaschinen entdeckt werden, sofern kein Link auf einer öffentlichen Website angezeigt wird (dies geschieht niemals), und um zu verhindern, dass sie von Google indiziert werden.

Ich habe eine Regel /etc/httpd/conf.d/robots.confmit dem folgenden Alias ​​eingerichtet:

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

Der Alias ​​leitet alle Anforderungen an den Speicherort robots.txt an eine gesperrte Datei weiter. Dies bedeutet, dass es keine Rolle spielt, was in der robots.txt-Datei im Magento-Staging-Stammverzeichnis enthalten ist. Der Server stellt immer die folgenden Regeln bereit:

User-agent: *
Disallow: /

Durch die Angabe von location und satisf any kann die robots.txt-Datei unabhängig von der Authentifizierung an alle Benutzer gesendet werden, da wir keine globalen disallow from anyRegeln haben.

Für die Kennwortauthentifizierung habe ich die Regeln eingerichtet, damit ich die Authentifizierung vorübergehend auf einer einzelnen Site öffnen kann, indem ich Satisfy anysie zur .htaccessDatei hinzufüge . Dies liegt daran, dass wir mehrere Stage-Sites auf demselben dedizierten internen Staging-Server ausführen. Außerdem können allow fromRegeln festgelegt werden Satisfy any, um die Kennwortauthentifizierung für bestimmte IP-Adressen zu entfernen und gleichzeitig für alle anderen Benutzer zu verwalten (sofern dies wirklich erforderlich ist).

Der Grund, warum ich kein allgemeines IP-basiertes Whitelisting (dh keine kennwortbasierte Authentifizierung) mag, ist, dass die IP-Adressen des Clients nicht immer statisch sind. Das heißt, wir müssten dann ihre IPs aktualisieren, um sie (möglicherweise) täglich oder wöchentlich zugreifen zu können, je nachdem, wie lange ihre ISPs den DHCP-Vertrag halten.

Für DNS verwenden wir Platzhalter-DNS, damit DNS-Crawler nicht alle Hostnamen der Stage-Site abrufen, für die öffentliches DNS erforderlich ist. Google wird tatsächlich eine Website aus DNS-Einträgen abrufen. Dies verhindert dies, was für sie der einzige Weg ist, es zu finden, wenn jemand einen Link irgendwo liegen lässt. Wenn Sie die Robots-Datei jedoch zwingen, eine Verbotsregel zu liefern, wird die Indizierung gestoppt, wenn sie einen Link findet.

Wenn ich an die Stelle eines Händlers treten würde, der eine Bühnenwebsite für die Unternehmenswebsite betreibt, würde ich die Dinge ein wenig anders machen und den gesamten Datenverkehr auf der Bühnenbox blockieren, sofern keine IP-Adressen bekannt werden. Jeder, der an der Site remote (intern) arbeitet, muss eine Verbindung zu einem Unternehmens-VPN herstellen, um auf diese zuzugreifen, wenn er keine statische IP-Adresse hat, die ich auf die Whitelist setzen könnte.

Ein öffentliches DNS ist ein Muss, wenn Sie beispielsweise Integrationen von Zahlungsprozessoren testen möchten, die im Gegensatz zu den meisten Gateways Rückrufe an den Server senden müssen, um den Zahlungsvorgang zu durchlaufen.

Ich habe ein Modul entwickelt, mit dem ein Wartungsmodus aktiviert werden kann, der den Zugriff von Benutzern auf das Fronted blockiert (nicht der Administrator, der mit der nativen IP-Blockierungsfunktion von Magento eingeschränkt werden kann).

Sie können tatsächlich zulassen, dass einige IP-Adressen auf das Frontend zugreifen, auch wenn der Wartungsmodus aktiviert ist.

Vielleicht können Sie es versuchen, in der Hoffnung, es könnte helfen. Es ist kostenlos und Open Source: https://github.com/aleron75/Webgriffe_Maintenance

Dazu gibt es verschiedene Möglichkeiten.

Eine Möglichkeit wäre, Ihre Entwickler dazu zu bringen, ihre / hosts-Datei mit der richtigen IP-Adresse zu bearbeiten.

Es gibt eine Erweiterung, die behauptet, dies auf elegantere Weise zu tun: http://www.magentocommerce.com/magento-connect/et-ip-security.html

Da Sie in den Kommentaren nach Lack gefragt haben, teile ich meine Konfiguration mit der HTTP-Basisauthentifizierung mit Lack, einschließlich Ausnahmen. Sie müssen es in der VCL einrichten, da sonst immer auf zwischengespeicherte Seiten zugegriffen werden kann.

Lack VCL Konfiguration

Ich möchte bestimmte IP-Adressen und Bereiche für Rückrufe von Zahlungsanbietern und solche zulassen, die ich oben in der VCL-Datei als ACL definiere:

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

Fügen Sie dann am Ende von vcl_recvkurz vor Folgendes hinzu return (lookup):

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

paymentist die oben definierte ACL. Ich erlaube auch den Zugriff auf die Upload-Route, da der Flash-Uploader keine Authentifizierungsheader sendet und daher hinter HTTP Basic Auth fehlschlägt. Ersetzen Sie ADMIN durch Ihre tatsächliche Administrator-URL. Sie können auf diese Weise weitere Ausnahmen hinzufügen.

XXXXXXXXX ist der Base64-verschlüsselte Benutzername und das Passwort. Führen Sie auf der Shell Folgendes aus, um diese Zeichenfolge zu generieren:

$ echo -n "username:password" | base64

Fügen Sie dies am Ende der VCL hinzu, um die 401-Fehlerantwort zu definieren:

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);
}
}