Bazı erişim kısıtlamaları ile bir hazırlama ortamı kurmak için en iyi yolu anlamaya çalışıyorum.

Basit çözüm Temel Kimlik Doğrulama'yı atmak olacaktır, ancak daha sonra performans optimizasyonlarını ve erişmek istediğim diğer benzer harici hizmetleri test ederken Google Page Speed ​​Insights'ı ona işaret edemeyeceğim.

Arama motorlarında görünmesini önlemek için robots.txt ile tamamen herkese açık hale getirilebilir. Ancak endişem, robots.txt dosyasında herhangi bir hata riskinin oldukça yüksek olması ve bunun için endişelenmemeyi tercih etmem.

Arama motorlarını engellemezseniz (veya bazılarını görmezden gelirseniz), canlı müşterileri hazırlama sitenize sipariş vererek mutlu edeceksiniz.

Daha da kötüsü, robots.txt dosyasını yanlışlıkla üretime dağıtırsanız, tüm Google meyve suyunuzu ve iyi bir satış yığınınızı kaybedersiniz.

Sevdiğim seçenek basit bir IP adresi kısıtlaması. Ancak, değişiklik yaparken riski tekrar en aza indirmek için Nginx'i yeniden başlatmak zorunda kalmadan kısıtlamalar ekleyebilmeyi / kaldırabilmeyi isterim.

Bu nedenle, etkinleştirildiğinde geliştirici IP adreslerine bakacak ve yalnızca kullanıcının IP adresi (veya X_FORWARDED_FOR) ile eşleşirse siteye (ön ve arka uç) erişime izin verecek hızlı bir modüle doğru eğilmeye başlıyorum.

Bunun makul bir çözüm gibi gelip gelmediğini veya eksik olduğumdan daha basit bir şey olup olmadığını merak ediyorum.

GÜNCELLEME: robots.txt dosyasının yerel bir arka uç anahtarı ile kontrol edilebileceği ve demo mağaza bildiriminin herhangi bir yasal müşteri siparişini önleyeceği göz önüne alındığında ve gerçekten sahneleme halka erişim konusunda endişe duymadığım için Phil'in çözümünü seviyorum.

Ancak evreleme sitelerine erişimi kısıtlamak isteyen herkes için, Kris'in çözümünün gitmenin yolu olduğunu düşünüyorum.

GÜNCELLEME 2: Sistem Yapılandırması> Tasarım> HTML Kafası'nda robots.txt seçeneklerinin ne yapması gerektiğinden% 100 emin değilim, ancak benim durumumda - ve kısa bir aramadan bu yaygın görünüyor - sadece düz bir robots.txt var metin dosyası kullanılmakta, böylece yapılandırma seçeneğine uyulmamaktadır.

Şimdilik bakım modülü ile gidiyorum: https://github.com/aleron75/Webgriffe_Maintenance

Birkaç öneri - bazıları yerleşik!

- Geliştirici IP kısıtlaması , Sistem Yapılandırma> Geliştirici'de yerleşiktir:

Bu IP erişimini kısıtlamaz. Yürü.

• IP kısıtlaması zor ve bunu kişisel olarak güvenlik duvarında ele almayı tercih ediyorum. IP tabloları da, htaccess kısıtlaması veya $_SERVER['REMOTE_ADDR']index.php dosyasında olduğu gibi bir adaydır .

• Sistem Yapılandırması> Tasarım> HTML Başlığı'ndaki hazırlık sırasında CMS'deki varsayılan sayfa başına robot metalarını NOINDEX / NOFOLLOW olarak güncelleyin:

• Aynı yapılandırma alanında, demo mağaza bildirimi görüntüleme özelliği :

Birincil (çoğu) evreleme ortamlarını kilitlemenin birincil yolu BASIC kimlik doğrulamasıdır. Ancak, motorlar tarafından bulunmalarını önlemek, herkese açık bir web sitesinde görünen bir bağlantıyı engellemek (ve asla bu olmaz) ve ayrıca Google tarafından dizine eklenmelerini önlemek için önleyici tedbirlerimiz var.

/etc/httpd/conf.d/robots.confAşağıdaki takma adla bir kural oluşturdum :

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

Takma ad, tüm istekleri robots.txt konumuna kilitli bir dosyaya yönlendirir. Bu, Magento hazırlama kökündeki robots.txt dosyasında ne olduğu önemli değil, sunucu her zaman aşağıdaki kuralları sunacaktır:

User-agent: *
Disallow: /

Konumu ve herhangi birini karşılama, global disallow from anykurallarımız olmadığından, kimlik doğrulaması ne olursa olsun robots.txt dosyasının herkese sunulmasını sağlar .

Parola kimlik doğrulaması Satisfy anyiçin, .htaccessdosyaya ekleyerek kimlik doğrulamayı geçici olarak tek bir sitede açabilmem için kurallar ayarladım . Bunun nedeni, aynı özel dahili evreleme sunucusunda birden çok aşamalı site çalıştırmamızdır. Ayrıca, herkes için koruyarak (gerçekten ihtiyacım olursa), belirli IP adreslerine şifre kimlik doğrulamasını kaldırmak için allow fromkuralların ayarlanmasına izin verir Satisfy any.

IP tabanlı beyaz listeyi (yani parola tabanlı kimlik doğrulaması olmadan) sevmememin nedeni, istemcinin IP adreslerinin her zaman statik olmamasıdır. Bu, İSS'lerinin DHCP'nin kiralama süresini ne kadar tuttuğuna bağlı olarak (potansiyel olarak) günlük veya haftalık olarak erişebilmeleri için IP'lerini güncellememiz gerektiği anlamına gelir.

DNS için, joker karakter DNS'yi kullanırız, böylece DNS tarayıcıları herkese açık DNS'ye sahip olması gereken tüm sahne alanı ana bilgisayar adlarını toplamaz. Google aslında DNS kayıtlarından bir site seçecektir. Bu, onları bulmanın tek yolu, birisinin bir yere bir bağlantı bırakmasıdır. Ancak robot dosyasını izin verme kuralına hizmet etmeye zorlamak, bir bağlantı bulmaları durumunda dizine eklemelerini durduracaktır.

Şirket web sitesi için bir sahne sitesi çalıştıran bir tüccar yerine, biraz farklı şeyler yaparım ve bilinen IP adresleri gelmedikçe, sahne kutusuna gelen tüm trafiği engellerdim. Sitede uzaktan (şirket içi) çalışan herkesin, beyaz listeye ekleyebileceğim statik bir IP'si yoksa erişmek için bir şirket VPN'sine bağlanması gerekir.

Çoğu ağ geçidinden farklı olarak, ödeme sürecinden geçmek için sunucuya geri arama yapmak zorunda olan ödeme işlemci entegrasyonları gibi şeyleri test etmeniz gerekiyorsa, genel DNS'ye sahip olmak şarttır.

Kullanıcıların ön cepheye erişmesini engellemenin aynı etkisiyle kullanılabilecek bir bakım modunu etkinleştirmek için bir modül geliştirdim (Magento'nun yerel IP engelleme özelliği ile sınırlı olabilecek yönetici değil).

Bakım modu etkin olsa bile bazı IP'lerin ön uca erişmesine izin verebilirsiniz.

Belki de yardımcı olacağını umarak deneyebilirsiniz. Ücretsiz ve açık kaynak: https://github.com/aleron75/Webgriffe_Maintenance

Bunu yapmanın birkaç farklı yolu var.

Bunun bir yolu, geliştiricilerin / hosts dosyasını doğru IP adresiyle düzenlemelerini sağlamaktır.

Bunun daha zarif bir şekilde yapıldığını iddia eden bir uzantı var: http://www.magentocommerce.com/magento-connect/et-ip-security.html

Yorumlarda Varnish'i sorduğunuzdan, yapılandırmamı istisnalar dahil Varnish kullanarak HTTP Temel Kimlik Doğrulaması ile paylaşacağım. VCL'de ayarlamanız gerekir, aksi takdirde önbelleğe alınmış sayfalara her zaman erişilebilir.

Vernik VCL yapılandırması

VCL dosyasının üst kısmında ACL olarak tanımladığım ödeme sağlayıcılarının geri çağrıları için belirli IP adreslerine ve aralıklarına izin vermek istiyorum:

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

Ardından aşağıdakilerin sonuna vcl_recvhemen önce aşağıdakileri ekleyin return (lookup):

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

paymentyukarıda tanımlanan ACL'dir. Flash yükleyici kimlik doğrulama başlıkları göndermediğinden ve HTTP Temel Kimlik Doğrulamasının arkasında başarısız olduğu için yükleme yoluna erişime de izin veriyorum. ADMIN'i gerçek yönetici URL'nizle değiştirin. Bu şekilde başka istisnalar ekleyebilirsiniz.

XXXOD, base64 kodlu kullanıcı adı ve şifredir. Bu dizeyi oluşturmak için kabukta aşağıdakileri çalıştırın:

$ echo -n "username:password" | base64

Ardından, 401 hata yanıtını tanımlamak için bunu VCL'nin sonuna ekleyin:

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