J'essaie de trouver la meilleure façon de configurer un environnement de transfert avec certaines restrictions d'accès.

La solution simple serait de lancer l'authentification de base, mais je ne serai pas en mesure de pointer Google Page Speed ​​Insights sur celle-ci tout en testant les optimisations de performances, ainsi que d'autres services externes similaires auxquels je veux accéder.

Pourrait le rendre complètement public avec robots.txt afin de l'empêcher d'apparaître dans les moteurs de recherche. Mais ma préoccupation est que le risque d'erreur dans le fichier robots.txt est assez élevé, et je préfère ne pas m'inquiéter à ce sujet.

Si vous ne bloquez pas les moteurs de recherche (ou si certains l'ignorent), vous obtiendrez des clients en direct qui passeront des commandes sur votre site de transit, ce qui ne les rendra pas heureux.

Ou pire encore, si vous déployez accidentellement le fichier robots.txt en production, vous perdrez tout votre jus Google et une bonne partie des ventes.

Donc, l'option que j'aime est une simple restriction d'adresse IP. Mais j'aimerais pouvoir ajouter / supprimer des restrictions sans avoir à redémarrer Nginx, juste pour minimiser à nouveau les risques lors des modifications.

Je commence donc à pencher vers un module rapide qui, lorsqu'il est activé, examinera les adresses IP des développeurs et n'autorisera l'accès au site (avant et arrière) que si l'adresse IP de l'utilisateur (ou X_FORWARDED_FOR) correspond.

Vous vous demandez si cela semble être une solution raisonnable ou s'il y a quelque chose de plus simple qui me manque.

MISE À JOUR: Étant donné que le fichier robots.txt peut être contrôlé via un commutateur principal natif et que l'avis de magasin de démonstration empêchera toute commande client légitime, et comme je ne suis vraiment pas préoccupé par l'accès public au site de transfert, j'aime la solution de Phil.

Mais pour tous ceux qui veulent restreindre l'accès à leur site de transfert, je pense que la solution de Kris est la voie à suivre.

MISE À JOUR 2: Je ne suis pas sûr à 100% de ce que les options robots.txt sont censées faire dans System Config> Design> HTML Head, mais dans mon cas - et à partir d'une brève recherche, cela semble courant - j'ai juste un robot.txt plat fichier texte en place qui est utilisé, de sorte que l'option de configuration n'est pas respectée.

Je vais donc avec le module de maintenance pour l'instant: https://github.com/aleron75/Webgriffe_Maintenance

Quelques suggestions - certaines sont intégrées!

- La restriction IP du développeur est intégrée dans System Config> Developer:

Cela ne restreint pas l'accès IP. Avancer.

• La restriction IP est difficile et je préfère gérer cela au niveau du pare-feu, personnellement. Les tables IP sont également candidates, tout comme la restriction htaccess ou via $_SERVER['REMOTE_ADDR']index.php.

• Mettez à jour la méta par défaut des robots par page dans le CMS vers NOINDEX / NOFOLLOW pendant la mise en scène dans System Config> Design> HTML Head:

• Dans la même zone de configuration, est la possibilité d' afficher un avis de magasin de démonstration :

Notre principal moyen de verrouiller (la plupart) des environnements intermédiaires est l'authentification BASIC. Mais nous avons également mis en place des mesures préventives pour empêcher leur découverte par les moteurs, à moins qu'un lien n'apparaisse sur un site Web public (cela ne se produit jamais), et également pour empêcher leur indexation par Google.

J'ai configuré une règle /etc/httpd/conf.d/robots.confavec l'alias suivant:

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

L'alias achemine toutes les demandes vers l'emplacement robots.txt vers un fichier verrouillé. Cela signifie que peu importe ce qui se trouve dans le fichier robots.txt dans la racine de transfert Magento, le serveur appliquera toujours les règles suivantes:

User-agent: *
Disallow: /

L'emplacement et la satisfaction de tout permettent au fichier robots.txt d'être servi à n'importe qui, quelle que soit l'authentification, car nous n'avons pas de disallow from anyrègles globales .

Pour l'authentification par mot de passe, j'ai la configuration des règles afin que je puisse ouvrir l'authentification sur un seul site temporairement en l'ajoutant Satisfy anyau .htaccessfichier. En effet, nous exécutons des sites à plusieurs étapes sur le même serveur de transfert interne dédié. Il permettra également de définir des allow fromrègles ainsi que Satisfy anyde supprimer l'authentification par mot de passe pour des adresses IP spécifiques tout en la conservant pour tout le monde (si j'en ai vraiment besoin).

La raison pour laquelle je n'aime pas la liste blanche basée sur IP (c'est-à-dire sans authentification par mot de passe) est que les adresses IP du client ne sont pas toujours statiques. Ce qui signifie que nous devrons alors mettre à jour leurs adresses IP pour leur donner accès sur une base (potentiellement) quotidienne ou hebdomadaire en fonction de la durée pendant laquelle leur FAI DHCP détient le bail.

Pour le DNS, nous utilisons un DNS générique afin que les robots DNS ne récupèrent pas tous les noms d'hôte du site de scène qui doivent avoir un DNS public. Google récupérera en fait un site à partir des enregistrements DNS. Cela empêche cela, ce qui signifie que le seul moyen pour eux de le trouver est de laisser un lien quelque part. Mais en forçant le fichier robots à servir une règle d'interdiction, ils ne pourront plus l'indexer s'ils trouvent un lien.

Si j'étais à la place d'un marchand gérant un site de scène pour le site Web de l'entreprise, je ferais les choses un peu différemment et bloquerais tout simplement tout le trafic entrant dans la boîte de scène à moins qu'il ne s'agisse d'adresses IP connues. Toute personne travaillant à distance (en interne) sur le site serait tenue de se connecter à un VPN d'entreprise pour y accéder si elle ne disposait pas d'une adresse IP statique que je pouvais mettre sur liste blanche.

Avoir un DNS public est un must si vous devez tester des choses comme les intégrations de processeur de paiement, qui, contrairement à la plupart des passerelles, doivent rappeler le serveur pour passer par le processus de paiement.

J'ai développé un module pour activer un mode de maintenance qui peut être utilisé avec le même effet de bloquer les utilisateurs accédant à la façade (pas l'administrateur qui peut être limité avec la fonctionnalité de blocage IP natif de Magento).

Vous pouvez en effet autoriser certaines adresses IP à accéder au frontend même si le mode de maintenance est activé.

Vous pouvez peut-être essayer, en espérant que cela pourrait vous aider. C'est gratuit et open source: https://github.com/aleron75/Webgriffe_Maintenance

Il existe plusieurs façons de procéder.

Une façon serait de demander à vos développeurs de modifier leur fichier / hosts avec la bonne adresse IP.

Il existe une extension qui prétend le faire de manière plus élégante: http://www.magentocommerce.com/magento-connect/et-ip-security.html

Puisque vous avez posé des questions sur Varnish dans les commentaires, je vais partager ma configuration avec l'authentification HTTP de base à l'aide de Varnish, y compris les exceptions. Vous devez le configurer dans la VCL, sinon les pages mises en cache seraient toujours accessibles.

Configuration du vernis VCL

Je souhaite autoriser certaines adresses IP et plages pour les rappels des fournisseurs de paiement et autres, que je définis comme ACL en haut du fichier VCL:

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

Ajoutez ensuite ce qui suit à la fin de vcl_recv, juste avant return (lookup):

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

paymentest l'ACL définie ci-dessus. J'autorise également l'accès à la route de téléchargement car le téléchargeur Flash n'envoie pas d'en-têtes d'authentification et échoue donc derrière HTTP Basic Auth. Remplacez ADMIN par votre URL d'administration réelle. Vous pouvez ajouter toute autre exception de cette façon.

XXXXXXXXX est le nom d'utilisateur et le mot de passe encodés en base64. Exécutez ce qui suit sur le shell pour générer cette chaîne:

$ echo -n "username:password" | base64

Ajoutez ensuite ceci à la fin de la VCL pour définir la réponse d'erreur 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);
}
}