Sto cercando di capire il modo migliore per impostare un ambiente di gestione temporanea con alcune restrizioni di accesso.

La semplice soluzione sarebbe quella di lanciare l'autenticazione di base, ma non potrò indicarlo a Google Page Speed ​​Insights durante il test delle ottimizzazioni delle prestazioni, così come altri servizi esterni simili a cui voglio accedervi.

Potrebbe renderlo completamente pubblico con robots.txt per evitare che venga visualizzato nei motori di ricerca. Ma la mia preoccupazione è che il rischio di errori nel robots.txt sia piuttosto elevato e preferirei non dovermi preoccupare di questo.

Se non blocchi i motori di ricerca (o se alcuni lo ignorano), riceverai clienti dal vivo che effettuano ordini sul tuo sito di staging, il che non li renderà felici.

O peggio ancora, se distribuisci accidentalmente il file robots.txt alla produzione, perderai tutto il tuo succo di Google e una buona fetta delle vendite.

Quindi l'opzione che mi piace è una semplice restrizione dell'indirizzo IP. Ma mi piacerebbe poter aggiungere / rimuovere le restrizioni senza dover riavviare Nginx, solo per minimizzare nuovamente il rischio mentre si apportano modifiche.

Quindi sto cominciando a orientarmi verso un modulo rapido che, quando abilitato, esaminerà gli indirizzi IP degli sviluppatori e consentirà l'accesso al sito (front e backend) solo se l'indirizzo IP dell'utente (o X_FORWARDED_FOR) corrisponde.

Mi chiedo se questa sembra una soluzione ragionevole o se c'è qualcosa di più semplice che mi manca.

AGGIORNAMENTO: Dato che robots.txt può essere controllato tramite uno switch backend nativo e l'avviso del negozio demo eviterà qualsiasi ordine legittimo da parte dei clienti, e poiché non sono davvero preoccupato per l'accesso del pubblico al sito di staging, mi piace la soluzione di Phil.

Ma per chiunque voglia limitare l'accesso al proprio sito di staging, penso che la soluzione di Kris sia la strada da percorrere.

AGGIORNAMENTO 2: Non sicuro al 100% di cosa dovrebbero fare le opzioni di robots.txt in Configurazione di sistema> Progettazione> HTML Head, ma nel mio caso - e da una breve ricerca questo sembra essere comune - Ho solo un robots.txt piatto file di testo in atto che viene utilizzato, quindi l'opzione di configurazione non viene rispettata.

Quindi per ora vado con il modulo di manutenzione: https://github.com/aleron75/Webgriffe_Maintenance

Alcuni suggerimenti - alcuni sono integrati!

- La restrizione IP dello sviluppatore è integrata in Config sistema> Sviluppatore:

Questo non limita l'accesso IP. Muoviti.

• La restrizione dell'IP è dura e preferisco gestirla personalmente sul firewall. Anche le tabelle IP sono candidate, così come le restrizioni htaccess o tramite $_SERVER['REMOTE_ADDR']in index.php.

• Aggiorna il meta predefinito dei robot per pagina nel CMS su NOINDEX / NOFOLLOW durante la messa in scena in Configurazione di sistema> Progettazione> Testa HTML:

• Nella stessa area di configurazione, è la possibilità di visualizzare un avviso del negozio demo :

Il nostro mezzo principale per bloccare (la maggior parte) degli ambienti di gestione temporanea è l'autenticazione BASIC. Ma abbiamo anche messo in atto misure preventive per impedire che vengano scoperte dai motori, escludendo un link che appare su un sito Web pubblico (ciò non accade mai) e anche per impedire che vengano indicizzate da Google.

Ho impostato una regola /etc/httpd/conf.d/robots.confcon il seguente alias:

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

L'alias indirizza tutte le richieste al percorso robots.txt in un file bloccato. Ciò significa che non importa cosa si trova nel file robots.txt nella radice di staging Magento, il server servirà sempre le seguenti regole:

User-agent: *
Disallow: /

L'ubicazione e il soddisfacimento di qualsiasi consente al file robots.txt di essere offerto a chiunque indipendentemente dall'autenticazione poiché non abbiamo disallow from anyregole globali .

Per l'autenticazione della password, ho impostato le regole in modo da poter aprire temporaneamente l'autenticazione su un singolo sito aggiungendo Satisfy anyal .htaccessfile. Ciò è dovuto al fatto che gestiamo siti a più stadi sullo stesso server di gestione temporanea interno dedicato. Permetterà inoltre di impostare allow fromregole insieme Satisfy anya rimuovere l'autenticazione della password per indirizzi IP specifici mantenendola per tutti gli altri (se ne ho davvero bisogno).

Il motivo per cui non mi piace la whitelist basata su IP su tutta la linea (ovvero senza autenticazione basata su password) è perché gli indirizzi IP del client non sono sempre statici. Ciò significa che dovremmo quindi aggiornare i loro IP per ottenere l'accesso su base (potenzialmente) giornaliera o settimanale a seconda di quanto tempo il loro ISP DHCP mantiene il contratto di locazione.

Per DNS, utilizziamo DNS con caratteri jolly in modo che i crawler DNS non raccolgano su tutti i nomi host del sito dello stage che devono disporre di DNS pubblico. Google raccoglierà effettivamente un sito dai record DNS. Questo lo impedisce, il che significa che l'unico modo per trovarli è se qualcuno lascia un collegamento che si trova da qualche parte. Ma forzando il file robot a servire una regola di non consentire, si fermerà l'indicizzazione se trovano un collegamento.

Se fossi al posto di un commerciante che gestisce un sito di palcoscenico per il sito Web dell'azienda, farei le cose in modo un po 'diverso e bloccherei semplicemente tutto il traffico che arriva allo stage box a meno che non arrivino indirizzi IP noti. Chiunque lavori sul sito in remoto (internamente) dovrebbe connettersi a una VPN aziendale per accedere se non avesse un IP statico che potrei inserire nella whitelist.

Avere DNS pubblico è un must se devi testare cose come le integrazioni del processore di pagamento, che, a differenza della maggior parte dei gateway, devono effettuare chiamate al server per passare attraverso il processo di pagamento.

Ho sviluppato un modulo per abilitare una modalità di manutenzione che può essere utilizzata con lo stesso effetto di blocco degli utenti che accedono al fronted (non all'amministratore che può essere limitato con la funzione di blocco IP nativo di Magento).

Puoi infatti consentire ad alcuni IP di accedere al frontend anche con la modalità di manutenzione abilitata.

Forse puoi provarlo, sperando che possa aiutare. È gratuito e open source: https://github.com/aleron75/Webgriffe_Maintenance

Esistono diversi modi per farlo.

Un modo sarebbe quello di fare in modo che i tuoi sviluppatori modifichino il loro file / hosts con l'indirizzo IP corretto.

Esiste un'estensione là fuori che sostiene di farlo in un modo più elegante: http://www.magentocommerce.com/magento-connect/et-ip-security.html

Dato che hai chiesto informazioni su Varnish nei commenti, condividerò la mia configurazione con l'autenticazione di base HTTP usando Varnish, comprese le eccezioni. Devi impostarlo nel VCL, altrimenti le pagine memorizzate nella cache sarebbero sempre accessibili.

Vernice VCL

Voglio consentire determinati indirizzi IP e intervalli per le richiamate dei fornitori di servizi di pagamento e simili, che definisco ACL nella parte superiore del file VCL:

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

Quindi aggiungere quanto segue alla fine di vcl_recv, appena prima return (lookup):

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

paymentè l'ACL definito sopra. Consento anche l'accesso al percorso di caricamento perché l'uploader Flash non invia le intestazioni di autenticazione e quindi non riesce dietro HTTP Basic Auth. Sostituisci ADMIN con il tuo vero URL amministratore. Puoi aggiungere altre eccezioni in questo modo.

XXXXXXXXX è il nome utente e la password codificati in base64. Eseguire quanto segue sulla shell per generare questa stringa:

$ echo -n "username:password" | base64

Quindi aggiungere questo alla fine del VCL per definire la risposta di errore 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);
}
}