Configurando o ambiente de armazenamento temporário Magento com acesso restrito


18

Estou tentando descobrir a melhor maneira de configurar um ambiente de armazenamento temporário com algumas restrições de acesso.

A solução simples seria ativar a autenticação básica, mas não poderei apontar o Google Page Speed ​​Insights para ele enquanto testo as otimizações de desempenho, bem como outros serviços externos semelhantes aos quais quero acessá-lo.

Poderia torná-lo completamente público com o robots.txt para impedir que ele apareça nos mecanismos de pesquisa. Mas minha preocupação é que o risco de qualquer erro no robots.txt seja bastante alto, e eu prefiro não ter que me preocupar com isso.

Se você não bloquear os mecanismos de pesquisa (ou se alguns o ignorarem), você receberá clientes ativos que fazem pedidos no site de preparação, o que não os fará felizes.

Ou pior, se você acidentalmente implantar o robots.txt na produção, perderá todo o seu suco do Google e uma boa parte das vendas.

Portanto, a opção que eu mais gosto é uma simples restrição de endereço IP. Mas eu adoraria poder adicionar / remover restrições sem precisar reiniciar o Nginx, apenas para minimizar novamente os riscos ao fazer alterações.

Portanto, estou começando a me inclinar para um módulo rápido que, quando ativado, examinará os endereços IP do desenvolvedor e permitirá apenas o acesso ao site (front-end e back-end) se o endereço IP do usuário (ou X_FORWARDED_FOR) corresponder a ele.

Querendo saber se isso soa como uma solução razoável ou se há algo mais simples que estou perdendo.

ATUALIZAÇÃO: Como o robots.txt pode ser controlado por meio de um switch de back-end nativo, o aviso da loja demo evitará pedidos legítimos de clientes e, como não estou realmente preocupado com o acesso público ao site de preparação, eu gosto da solução de Phil.

Mas para quem quer restringir o acesso ao site de preparação, acho que a solução da Kris é o caminho a seguir.

ATUALIZAÇÃO 2: Não tenho 100% de certeza do que as opções robots.txt devem fazer em System Config> Design> HTML Head, mas no meu caso - e a partir de uma breve pesquisa, isso parece ser comum - eu só tenho um robots.txt simples arquivo de texto em uso, para que a opção de configuração não seja respeitada.

Então, eu estou indo com o módulo de manutenção por enquanto: https://github.com/aleron75/Webgriffe_Maintenance

Respostas:


6

Algumas sugestões - algumas estão embutidas!

- A restrição de IP do desenvolvedor é incorporada em System Config> Developer:

Isso não restringe o acesso IP. Siga em frente.

  • A restrição de IP é difícil e eu prefiro lidar com isso no firewall, pessoalmente. As tabelas IP também são candidatas, assim como a restrição htaccess ou via $_SERVER['REMOTE_ADDR']index.php.

  • Atualize a meta padrão de robôs por página no CMS para NOINDEX / NOFOLLOW durante a preparação em System Config> Design> HTML Head:

insira a descrição da imagem aqui

  • Na mesma área de configuração, está a capacidade de exibir um aviso da loja demo :

insira a descrição da imagem aqui


11
Obrigado Phil. Eu meio que tinha esquecido que os robôs eram uma opção de back-end padrão, acho que torna um pouco menos arriscado apenas usar isso, em vez de mexer manualmente com os arquivos robots.txt. Eu estava realmente ciente das restrições de IP do desenvolvedor, mas elas não ajudam a restringir o acesso ao site, certo? Apenas para recursos de desenvolvedor? E o aviso de demonstração - você deve definitivamente evitar que os clientes façam pedidos por engano, boa ligação.
Kalenjordan

11
Puxa, você está certo. Não tenho ideia de como não sabia disso.
philwinkle

11

Nosso principal meio de bloquear (na maioria) os ambientes de armazenamento temporário é a autenticação BASIC. Mas também temos medidas preventivas para impedir que sejam descobertas por mecanismos, barrando um link que aparece em um site público (isso nunca acontece) e também para impedir que sejam indexadas pelo Google.

Configurei uma regra /etc/httpd/conf.d/robots.confcom o seguinte alias:

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

O alias encaminha todas as solicitações para o local robots.txt para um arquivo bloqueado. Isso significa que não importa o que está no arquivo robots.txt na raiz temporária do Magento, o servidor sempre servirá as seguintes regras:

User-agent: *
Disallow: /

A localização e a satisfação de qualquer um permitem que o arquivo robots.txt seja veiculado por qualquer pessoa, independentemente da autenticação, pois não temos disallow from anyregras globais .

Para a autenticação de senha, eu tenho as regras configuradas para que eu possa abrir temporariamente a autenticação em um único site adicionando Satisfy anyao .htaccessarquivo. Isso ocorre porque executamos vários sites de estágio no mesmo servidor de armazenamento temporário interno dedicado. Ele também permitirá definir allow fromregras, além Satisfy anyde remover a autenticação de senha para endereços IP específicos, mantendo-a para todos os outros (se eu realmente precisar).

O motivo de eu não gostar da lista de permissões baseada em IP em geral (ou seja, sem autenticação por senha) é porque os endereços IP do cliente nem sempre são estáticos. O que significa que teríamos que atualizar seus IPs para acessá-los (potencialmente) diariamente ou semanalmente, dependendo de quanto tempo os seus ISPs DHCP mantêm a concessão.

Para DNS, usamos DNS curinga para que os rastreadores de DNS não sejam capturados em todos os nomes de host do site de estágio que precisam ter DNS público. O Google realmente selecionará um site nos registros DNS. Isso impede que, o que significa que a única maneira de encontrá-lo é se alguém deixar um link em algum lugar. Mas, ao forçar o arquivo de robôs a servir uma regra de proibição, eles os impedirão de indexá-lo se encontrarem um link.

Se eu estivesse no lugar de um comerciante executando um site de palco para o site da empresa, faria as coisas de maneira um pouco diferente e iria bloquear todo o tráfego que chegasse à caixa de palco, a menos que viesse endereços IP conhecidos. Qualquer pessoa que trabalhe no site remotamente (internamente) deverá se conectar a uma VPN da empresa para acessar se não tiver um IP estático que eu possa colocar na lista de permissões.

Ter DNS público é essencial se você precisar testar coisas como integrações de processadores de pagamento, que, diferentemente da maioria dos gateways, devem fazer retornos de chamada para o servidor para passar pelo processo de pagamento.


2
Isso é realmente atencioso. Nós também usamos auth BASIC, embora, na maioria das vezes ele apresenta os mesmos desafios para encenar que você chamar acima: processadores de pagamento, etc.
philwinkle

6

Eu desenvolvi um módulo para habilitar um modo de manutenção que pode ser usado com o mesmo efeito de bloquear usuários acessando o front-end (não o administrador que pode ser limitado ao recurso nativo de bloqueio de IP do Magento).

Você pode permitir que alguns IPs acessem o frontend, mesmo com o modo de manutenção ativado.

Talvez você possa tentar, esperando que possa ajudar. É gratuito e de código aberto: https://github.com/aleron75/Webgriffe_Maintenance


+1 Bom! Este é exatamente o tipo de módulo que eu tinha em mente. Você já testou por trás do verniz?
kalenjordan

Oi, infelizmente não testei atrás do Varnish, desculpe. Você faria isso? ;-)
Alessandro Ronchi

Trabalhando no meu ambiente de preparação. Eu não tinha certeza se essa lógica funcionaria b / c. Eu vi o REMOTE_ADDRendereço disponível, mas não o correto, por isso acho que seria melhor comparar com um REMOTE_ADDR ou outroX_FORWARDED_FOR . Embora funcione bem na encenação, ainda não estou muito preocupado em investigar pessoalmente.
kalenjordan

4

Existem várias maneiras diferentes de fazer isso.

Uma maneira seria fazer com que seus desenvolvedores editassem seus arquivos / hosts com o endereço IP correto.

Existe uma extensão por aí que afirma fazer isso de uma maneira mais elegante: http://www.magentocommerce.com/magento-connect/et-ip-security.html


11
Obrigado Kris! Acho que estou inclinado a usar os recursos da loja de demonstração agora que penso nisso. Como não tenho que brincar manualmente com o robots.txt e ter o aviso da loja demo, acho que é o suficiente. Mas para quem quer restringir o acesso à preparação, acho que o módulo que você encontrou é o caminho a percorrer. Obrigado!!
precisa saber é o seguinte

2

Como você perguntou sobre o Varnish nos comentários, vou compartilhar minha configuração com a autenticação básica HTTP usando o Varnish, incluindo exceções. É necessário configurá-lo na VCL, caso contrário, as páginas em cache estarão sempre acessíveis.

Configuração de verniz VCL

Quero permitir determinados endereços IP e intervalos para retornos de chamada de provedores de pagamento e outros, que eu defino como ACL na parte superior do arquivo VCL:

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

Em seguida, adicione o seguinte no final de vcl_recv, pouco antes return (lookup):

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

paymenté a ACL definida acima. Também permito acesso à rota de upload porque o Flash Uploader não envia cabeçalhos de autenticação e, portanto, falha por trás da autenticação básica HTTP. Substitua ADMIN pelo seu URL de administrador real. Você pode adicionar outras exceções dessa maneira.

XXXXXXXXX é o nome de usuário e a senha codificados em base64. Execute o seguinte no shell para gerar esta sequência:

$ echo -n "username:password" | base64

Em seguida, adicione isso no final da VCL para definir a resposta do erro 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);
}
}
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.