Estoy tratando de descubrir la mejor manera de configurar un entorno de ensayo con algunas restricciones de acceso.

La solución simple sería lanzar la autenticación básica, pero luego no podré apuntar a Google Page Speed ​​Insights mientras pruebo las optimizaciones de rendimiento, así como otros servicios externos similares a los que quiero acceder.

Podría hacerlo completamente público con robots.txt para evitar que aparezca en los motores de búsqueda. Pero mi preocupación es que el riesgo de cualquier error en el archivo robots.txt es bastante alto, y prefiero no tener que preocuparme por eso.

Si no bloquea los motores de búsqueda (o si algunos lo ignoran), obtendrá clientes en vivo que hagan pedidos a su sitio de preparación, lo que no los hará felices.

O peor aún, si implementa accidentalmente el archivo robots.txt en producción, perderá todo su jugo de Google y una buena parte de las ventas.

Entonces, la opción que me gusta es una simple restricción de dirección IP. Pero me encantaría poder agregar / eliminar restricciones sin tener que reiniciar Nginx, solo para minimizar nuevamente el riesgo al hacer cambios.

Así que estoy empezando a inclinarme hacia un módulo rápido que, cuando esté habilitado, analizará las direcciones IP del desarrollador y solo permitirá el acceso al sitio (frontal y posterior) si la dirección IP del usuario (o X_FORWARDED_FOR) coincide.

Me pregunto si esto suena como una solución razonable o si hay algo más simple que me estoy perdiendo.

ACTUALIZACIÓN: dado que el archivo robots.txt se puede controlar a través de un conmutador backend nativo y el aviso de la tienda de demostración evitará cualquier pedido legítimo de los clientes, y dado que realmente no me preocupa el acceso público al sitio de preparación, me gusta la solución de Phil.

Pero para cualquiera que quiera restringir el acceso a su sitio de preparación, creo que la solución de Kris es el camino a seguir.

ACTUALIZACIÓN 2: no estoy 100% seguro de lo que se supone que deben hacer las opciones de robots.txt en Configuración del sistema> Diseño> Cabecera HTML, pero en mi caso, y de una breve búsqueda, esto parece ser común, solo tengo un robots.txt plano archivo de texto en el lugar que se está utilizando, por lo que esa opción de configuración no se respeta.

Así que voy con el módulo de mantenimiento por ahora: https://github.com/aleron75/Webgriffe_Maintenance

Algunas sugerencias, ¡algunas están incorporadas!

- La restricción de IP del desarrollador está integrada en System Config> Developer:

Esto no restringe el acceso IP. Superar.

• La restricción de IP es difícil y prefiero manejar esto en el firewall, personalmente. Las tablas IP también son candidatas, como lo es la restricción htaccess o vía $_SERVER['REMOTE_ADDR']index.php.

• Actualice los metadatos predeterminados de los robots por página en el CMS a NOINDEX / NOFOLLOW mientras se encuentra en la configuración del sistema> Diseño> Cabecera HTML:

• En la misma área de configuración, está la capacidad de mostrar un aviso de tienda de demostración :

Nuestro medio principal para bloquear (la mayoría) de los entornos de ensayo es la autenticación BÁSICA. Pero también tenemos medidas preventivas para evitar que los motores los descubran, salvo que se muestre un enlace en un sitio web público (esto nunca sucede), y también para evitar que Google los indexe.

He configurado una regla /etc/httpd/conf.d/robots.confcon el siguiente alias:

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

El alias enruta todas las solicitudes a la ubicación de robots.txt a un archivo bloqueado. Esto significa que no importa lo que esté en el archivo robots.txt en la raíz provisional de Magento, el servidor siempre servirá las siguientes reglas:

User-agent: *
Disallow: /

La ubicación y satisfacer cualquier permite que el archivo robots.txt se sirva a cualquiera, independientemente de la autenticación, ya que no tenemos disallow from anyreglas globales .

Para la autenticación de contraseña, tengo la configuración de reglas para poder abrir la autenticación en un solo sitio temporalmente agregando Satisfy anyal .htaccessarchivo. Esto se debe a que ejecutamos sitios de varias etapas en el mismo servidor de almacenamiento interno dedicado. También permitirá establecer allow fromreglas junto con la Satisfy anyeliminación de la autenticación de contraseña a direcciones IP específicas mientras se mantiene para todos los demás (si realmente lo necesito).

La razón por la que no me gusta la lista blanca basada en IP en todos los ámbitos (es decir, sin autenticación basada en contraseña) es porque las direcciones IP del cliente no siempre son estáticas. Lo que significa que luego tendríamos que actualizar sus IP para obtener acceso (potencialmente) diariamente o semanalmente, dependiendo de cuánto tiempo sus ISP DHCP tengan el contrato de arrendamiento.

Para DNS, utilizamos DNS comodín para que los rastreadores de DNS no se activen en todos los nombres de host del sitio de etapa que necesitan tener DNS público. Google realmente recogerá un sitio de los registros DNS. Esto evita eso, lo que significa que la única forma para que lo encuentren es si alguien deja un enlace en algún lugar. Pero al obligar al archivo de robots a cumplir una regla de rechazo, se detendrá su indexación si encuentran un enlace.

Si estuviera en el lugar de un comerciante que ejecuta un sitio de escenario para el sitio web de la compañía, haría las cosas de manera un poco diferente y simplemente bloquearía todo el tráfico que llega a la caja del escenario a menos que venga direcciones IP conocidas. Cualquier persona que trabaje en el sitio de forma remota (internamente) debería conectarse a una VPN de la empresa para acceder si no tuviera una IP estática que pudiera incluir en la lista blanca.

Tener un DNS público es imprescindible si necesita probar cosas como las integraciones del procesador de pagos, que, a diferencia de la mayoría de las puertas de enlace, deben realizar devoluciones de llamada al servidor para pasar por el proceso de pago.

He desarrollado un módulo para habilitar un modo de mantenimiento que puede usarse con el mismo efecto de bloquear a los usuarios que acceden al frente (no el administrador que puede limitarse con la función de bloqueo de IP nativa de Magento).

De hecho, puede permitir que algunas IP accedan a la interfaz incluso con el modo de mantenimiento activado.

Tal vez puedas intentarlo, esperando que pueda ayudarte. Es gratis y de código abierto: https://github.com/aleron75/Webgriffe_Maintenance

Hay varias formas diferentes de hacer esto.

Una forma sería hacer que sus desarrolladores editen su archivo / hosts con la dirección IP correcta.

Hay una extensión que dice hacer esto de una manera más elegante: http://www.magentocommerce.com/magento-connect/et-ip-security.html

Como me preguntó sobre Varnish en los comentarios, voy a compartir mi configuración con la autenticación básica HTTP usando Varnish, incluidas las excepciones. Debe configurarlo en el VCL, de lo contrario las páginas en caché siempre serían accesibles.

Configuración de barniz VCL

Quiero permitir ciertas direcciones IP y rangos para devoluciones de llamadas de proveedores de pago y similares, que defino como ACL en la parte superior del archivo VCL:

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

Luego agregue lo siguiente al final de vcl_recv, justo antes return (lookup):

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

paymentes la ACL definida anteriormente. También permito el acceso a la ruta de carga porque el cargador de Flash no envía encabezados de autenticación y, por lo tanto, falla detrás de HTTP Basic Auth. Reemplace ADMIN con su URL de administrador real. Puede agregar cualquier otra excepción de esta manera.

XXXXXXXXX es el nombre de usuario y contraseña codificados en base64. Ejecute lo siguiente en el shell para generar esta cadena:

$ echo -n "username:password" | base64

Luego agregue esto al final de la VCL para definir la respuesta de error 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);
}
}