Siteyi hosting'e kurdunuz ve şimdi /staging veya /admin-old gibi kimsenin görmemesi gereken bir yol açık kaldı. Aklınıza gelen en hızlı yol klasör şifrelemedir. Bir dosya oluşturursunuz, içine iki satır yazarsınız ve tarayıcı parola ister. İş bitti. Buraya kadar doğru; sorun, bu iki satırın Google botunu, HTTPS yönlendirmesini ve kendi betiklerinizi de kilitlemesi ve sizin sitenin bozulduğunu düşünmenizle başlar.
htpasswd ile klasör şifreleme dört komutta
Apache ve LiteSpeed'de parola koruması .htaccess dosyası ve ayrı bir parola dosyası aracılığıyla yapılır. Önce parola dosyasını oluşturun. Sunucuda htpasswd kuruluysa:
htpasswd -c /home/USERNAME/.htpasswd staging
htpasswd /home/USERNAME/.htpasswd seconduser-c bayrağı yalnızca ilk seferde gelir ve dosyayı sıfırdan oluşturur. İkinci kez -c ile çalıştırırsanız önceki kullanıcı silinir. Bunu çok gördüm. SSH erişiminiz yoksa, aynı dosyayı çevrimiçi bir oluşturucuyla yapın ve File Manager ile yükleyin; yalnızca yolunu public_html dışına koyun ki web'den okunamasın.
Şimdi hedef klasörde .htaccess dosyasını oluşturun veya düzenleyin:
AuthType Basic
AuthName "Staging Area"
AuthUserFile /home/USERNAME/.htpasswd
Require valid-userAuthUserFile yolu mutlak olmalıdır. Göreli yol en sık yapılan hatalardan biridir ve sonucu parola istemi değil, 500 hatasıdır. Hosting'iniz PHP'yi CGI modunda çalıştırıyorsa, şu satırı da eklemeniz gerekebilir:
RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [E=HTTP_AUTHORIZATION:%1]Bu satır olmadan doğru parolayı girersiniz ve yine de 401 alırsınız. Nedeni, web sunucusunun Authorization başlığını PHP'ye iletmemesi ve betiğinizin kimsenin giriş yapmadığını düşünmesidir.
Klasör şifreleme neden test ortamı için işe yarar da gerçek içerik için yaramaz
Bir staging sürümü için bu yöntem en iyi seçimdir. Hızlı, kod değişikliği gerektirmez ve çerçeveden bağımsızdır. Ancak sitenin gerçek içeriğini korumak için yanlış seçimdir. Üç nedeni var.
- Basic Auth parolası HTTP üzerinden Base64 olarak iletilir; yani şifrelenmemiştir. HTTPS olmadan ağ yolundaki herkes parolayı okur.
- Çıkış yapmanın hiçbir yolu yoktur. Tarayıcı, pencereyi kapatmadığınız sürece parolayı tutar. Ortak bir bilgisayarda bu, sıradaki kişinin panelinize girmesi anlamına gelir.
- Kullanıcı yönetimi zordur. Her kişi için dosyaya yeni satır eklemeniz ve silmek için dosyayı elle düzenlemeniz gerekir.
Gerçek koruma istiyorsanız, oturum ve güvenli çerezle uygulama düzeyinde kimlik doğrulama veya IP tabanlı erişim kısıtlaması daha doğru bir seçimdir. Klasör şifrelemeyi "bir yolu geçici olarak kapatmak" için saklayın, "kalıcı güvenlik" için değil.
Klasör şifrelemenin tarayıcı botları ve Google indeksi üzerindeki etkisi
Bu bölümü çoğu site yöneticisi yanlış anlar. Bir klasör Basic Auth ile korunduğunda Googlebot 401 Unauthorized yanıtı alır. Bu yanıt "erişimin yok" demektir, "yokum" değil. Bu ikisi arasındaki fark, tüm meseledir.
Pratik sonuç: sayfa indeksten kaldırılmaz. O URL daha önce indekslenmişse ve arama sonuçlarında görünüyorsa, parolayı etkinleştirdikten sonra da sonuçlarda kalır; yalnızca kullanıcı ona tıkladığında parola sayfasına ulaşır. Bu en kötü durumdur: hem trafik gelir, hem kullanıcı hiçbir şey görmez, hem de hemen çıkma oranı yükselir.
Amaç indeksten kaldırmaksa, klasör şifreleme yanlış araçtır. 410 Gone yanıtı vermeli veya noindex etiketini kullanmalısınız. Amaç yalnızca geçici olarak kapatmaksa ve sonradan açılacaksa, 401 sorun yaratmaz.
Bir başka nokta: korumalı klasör sitenin ana yolu içindeyse ve diğer sayfalardan ona bir bağlantı işaret ediyorsa, Googlebot o bağlantıyı takip eder ve 401 alır. Bu kendi başına bir ceza değildir; ancak 401 yollarına çok sayıda iç bağlantı varsa, sitenin tarama bütçesi boşa harcanır. Parolayı uygulamadan önce o yola giden iç bağlantıları kaldırın.
Burada hata yapıyorlar: HTTPS yönlendirmesinin kilitlenmesi
Destek taleplerinde en sık gördüğüm sahne şudur: site yöneticisi "tüm siteyi kilitlemek" için klasör şifrelemeyi ana klasöre uygular. Sonra aynı .htaccess içine zorunlu HTTPS yönlendirmesini de koyar. Sonuç sonsuz bir döngüdür. Tarayıcı "yönlendirme sayısı izin verileni aştı" der ve site hiçbir tarayıcıda açılmaz.
Teknik neden: .htaccess içindeki kuralların yürütme sırası önemlidir. AuthType bloğu RewriteRule kurallarından önce gelirse, ilk HTTP isteği parola sayfasına çarpar, sonra yönlendirilir ve sonraki istekte yine aynı şey olur. Çözüm, HTTPS yönlendirmesini parolası olan klasörün içinde değil, <VirtualHost> bloğunda veya alan adı düzeyinde yapmaktır. Paylaşımlı hosting'deyseniz ve VirtualHost erişiminiz yoksa, yönlendirmeyi ana klasöre koyun ve parolayı yalnızca alt klasörlere uygulayın.
Bu hatayı teşhis etmenin işareti basittir: curl -I https://example.com ile arka arkaya birkaç kez 301 alırsınız ve hedef adres her seferinde kendine döner. Bunu görürseniz, önce parola bloğunu yorum satırı yapın ki site açılsın, sonra sırayı düzeltin.
Nginx'te klasör şifreleme
Nginx .htaccess dosyasını tanımaz. Siteniz Nginx'teyse ve .htaccess dosyası oluşturuyorsanız, hiçbir şey olmaz ve parolanın çalışmadığını düşünürsünüz. server veya location bloğuna şunu yazmalısınız:
location /staging/ {
auth_basic "Staging Area";
auth_basic_user_file /etc/nginx/.htpasswd;
}Parola dosyası aynı htpasswd ile oluşturulur, yalnızca yolu farklıdır. Linux paylaşımlı hosting'deyseniz ve kontrol paneliniz varsa, genellikle cPanel'deki "Password Protect Directories" seçeneği aynı işi yapar ve elle düzenlemeye gerek kalmaz. Web sunucusu üzerinde tam kontrol gerektiren yüksek trafikli siteler için özel sunucu, hem Nginx'i yapılandırma hem de kuralları doğru düzeyde uygulama özgürlüğünü verir.
Parolayı uygulamadan önce şu üç şeyi kontrol edin
AuthUserFileyolu mutlak vepublic_htmldışında olsun.ls -la /home/USERNAME/.htpasswdile varlığını doğrulayın.- Zorunlu HTTPS doğru yapılandırılmış olsun. Hosting'e SSL kurulumu ve yönlendirme döngüsü olmadan HTTPS zorlama rehberi tam da bu tuzağı açıklar.
- Korumalı yola hiçbir iç bağlantı kalmamış olsun.
grep -r "/staging" public_html/ile onları bulun.
Siteyi yeni kurdunuz ve klasör yapısının doğru olduğundan emin değilseniz, siteyi hosting'e yükleme rehberi, sonradan yolları elle düzeltmek zorunda kalmamanız için daha iyi bir başlangıç noktasıdır.
Büyük dosyalar hakkında pratik bir nokta: parola koyduğunuz klasör arşiv veya büyük yedek dosyaları içeriyorsa, her parola isteği tüm dosyayı diskten bir kez okur. Diski yavaş paylaşımlı planlarda bu, yüksek TTFB anlamına gelir. Yedek dosyalarını parola koymak yerine tamamen public_html dışına taşıyın. Yanıt hızını hızlıca kontrol etmek için ücretsiz web yöneticisi araçlarını kullanın.
Paylaşımlı hosting'deyseniz ve hangi olanaklara sahip olduğunuzu bilmek istiyorsanız, Linux hosting hem cPanel'i hem de parola dosyası oluşturmak için dosya sistemine erişimi olan bir seçenektir.
Sık sorulan sorular
Klasör şifreleme sayfayı Google'dan kaldırır mı?
Hayır. Googlebot 401 yanıtı alır ki bu "erişimim yok" demektir, "sayfa yok" değil. Sayfa indekste kalır ve kullanıcı sonuca tıkladığında parola sayfasına ulaşır. Gerçek kaldırma için 410 yanıtı vermeli veya noindex etiketi koymalısınız.
Klasör şifrelemeden sonra neden 500 hatası alıyorum?
Neredeyse her zaman AuthUserFile yolu yüzündendir. Göreli yol yazarsanız veya parola dosyası yoksa, Apache 401 değil 500 hatası verir. Yolu mutlak yazın ve ls ile dosyanın varlığını doğrulayın.
Nginx'te klasör şifreleme neden çalışmıyor?
Çünkü Nginx .htaccess dosyasını okumaz. auth_basic direktifini Nginx yapılandırmasındaki location bloğuna yazmalısınız. Yapılandırmaya erişiminiz yoksa, kontrol panelindeki Password Protect seçeneğini kullanın.
Tüm klasör yerine yalnızca bir dosyayı şifreleyebilir miyim?
Evet. .htaccess dosyasını klasöre koymak yerine <Files "secret.php"> bloğunu kullanabilir ve parola kurallarını içine yazabilirsiniz. Bu yöntem, aynı klasördeki diğer dosyaların genel kalması gerektiğinde işe yarar.