WordPress’e Ziyaretçiler Erişmeden Önce Girişi Zorunlu Kılma (5 Yöntem Açıklandı)

Bir WordPress sitesinde zorla giriş yapmak, kimliği doğrulanmamış her ziyaretçinin ana sayfa, yazılar, sayfalar ve medya dahil herhangi bir içeriği görüntüleyebilmeden önce giriş sayfasına yönlendirilmesi anlamına gelir. Bu davranış WordPress’te varsayılan olarak etkin değildir, ancak bir eklenti, functions.php içindeki özel bir kod parçacığı, sunucu düzeyinde HTTP kimlik doğrulaması veya tam bir üyelik platformu aracılığıyla uygulanabilir. Doğru yöntemi seçmek, erişim kontrolü gereksinimlerinize, teknik yetkinlik düzeyinize ve ayrıntılı rol tabanlı kısıtlamalara mı yoksa basit bir site geneli kapıya mı ihtiyaç duyduğunuza bağlıdır.

Bu kılavuz, uç durumlar, tuzaklar ve her yaklaşım arasındaki mimari farklılıklar dahil olmak üzere beş uygulama yöntemini teknik derinlikte ele almaktadır.

Neden WordPress Sitesinde Zorla Giriş Yapılır

Zorunlu kimlik doğrulama kullanım senaryoları, her biri farklı teknik sonuçlara sahip dört farklı kategoriye ayrılır:

Özel intranetler ve dahili araçlar. WordPress üzerinde İK portalları, proje wiki’leri veya dahili belgeler çalıştıran şirketlerin hiçbir içeriğin kamuya açık olarak dizine eklenmediğinden veya erişilebilir olmadığından emin olması gerekir. Burada doğru yaklaşım, yalnızca yazı düzeyinde görünürlük ayarları değil, site geneli bir giriş kapısıdır.

Üyelik ve abonelik siteleri. Ücretli içerik platformları, yalnızca kayıtlı ve ödeme yapan üyelerin korunan kaynaklara erişmesini gerektirir. Üyelik eklentileri, kimlik doğrulama katmanının üzerine ödeme kapısı ekler.

Müşteri portalları ve ajans teslimatları. Ajanslar sıklıkla kamuya açık olmaması gereken hazırlık siteleri veya müşteriye yönelik panolar sunar. Hafif kod tabanlı veya .htaccess yaklaşımı, eklenti yükü eklemeden burada iyi çalışır.

Düzenlenmiş veya hassas veri ortamları. Sağlık, hukuk veya finans alanındaki WordPress dağıtımları, temel uyumluluk kontrolü olarak kimlik doğrulaması gerektirebilir. Bu durumlarda, sunucu düzeyinde HTTP Basic Auth, WordPress uygulamasından bağımsız ek bir katman sağlar.

Çoğu kılavuzun atladığı kritik bir mimari nokta: WordPress düzeyinde giriş zorunluluğu yalnızca WordPress uygulama katmanı aracılığıyla işlenen içeriği korur. wp-content/uploads/ içindeki statik dosyalar, sunucu düzeyinde ayrıca koruma eklemediğiniz sürece doğrudan URL aracılığıyla kamuya açık olarak erişilebilir kalır. Bu ayrım, hassas belgeler veya medya içeren siteler için son derece önemlidir.

Yöntem 1: Force Login Eklentisi (Çoğu Site İçin Önerilen)

Kevin Vess tarafından geliştirilen Force Login eklentisi, site geneli kimlik doğrulama zorunluluğu için en güvenilir ve yaygın olarak denetlenmiş seçenektir. İstekleri template_redirect kancasında — WordPress’in hangi şablonu işleyeceğine karar verdiği noktada — yakalar ve herhangi bir içerik sunulmadan önce kimliği doğrulanmamış kullanıcıları yönlendirir.

Kurulum

1. WordPress panelinizde Eklentiler > Yeni Ekle bölümüne gidin.
2. Force Login (yazar: Kevin Vess) için arama yapın.
3. Şimdi Yükle‘ye, ardından Etkinleştir‘e tıklayın.

Herhangi bir yapılandırma gerekmez. Etkinleştirildikten sonra, kimliği doğrulanmamış her istek wp-login.php adresine yönlendirilir. Eklenti, kendi kendini kilitlemeyi önlemek için giriş sayfasının kendisini, wp-cron.php uç noktasını ve XML-RPC’yi otomatik olarak beyaz listeye ekler.

Giriş Sonrası Yönlendirmeyi Özelleştirme

Varsayılan olarak, WordPress kullanıcıları girişten sonra yönetici paneline yönlendirir. Ön uç üyelik siteleri için, büyük olasılıkla bunun yerine belirli bir sayfaya yönlendirmek isteyeceksiniz. Aşağıdaki filtreyi aktif temanızın functions.php dosyasına veya siteye özgü bir eklentiye ekleyin:

add_filter( 'login_redirect', 'custom_post_login_redirect', 10, 3 );

function custom_post_login_redirect( $redirect_to, $requested_redirect_to, $user ) {
    // Redirect subscribers to the member dashboard, admins to wp-admin
    if ( isset( $user->roles ) && in_array( 'subscriber', $user->roles ) ) {
        return home_url( '/member-dashboard/' );
    }
    return $redirect_to;
}

Belirli URL’leri Beyaz Listeye Alma

Bazı entegrasyonlar — ödeme ağ geçidi geri aramaları, REST API tüketicileri, webhook uç noktaları — site kapılı olsa bile kamuya açık kalmalıdır. Force Login eklentisi bunun için bir filtre sağlar:

add_filter( 'v_forcelogin_bypass', 'forcelogin_whitelist_endpoints', 10, 2 );

function forcelogin_whitelist_endpoints( $bypass, $url ) {
    // Allow WooCommerce payment gateway IPN callbacks
    if ( strpos( $url, '/wc-api/' ) !== false ) {
        return true;
    }
    // Allow a specific REST API namespace
    if ( strpos( $url, '/wp-json/my-plugin/v1/' ) !== false ) {
        return true;
    }
    return $bypass;
}

Yaygın tuzak: Başsız ön uçlar veya mobil uygulamalar tarafından kullanılan REST API uç noktalarını beyaz listeye almayı unutmak, bu entegrasyonları sessizce bozacaktır. Site geneli giriş zorunluluğunu etkinleştirmeden önce her zaman aktif entegrasyonlarınızı denetleyin.

Yöntem 2: functions.php İçinde Özel Kod (Eklentisiz)

Minimal eklenti ayak izi tercih eden geliştiriciler için, doğrudan functions.php dosyasına bir giriş zorunluluğu kancası eklemek, Force Login eklentisiyle aynı sonucu verir. Bu, hazırlık ortamları, müşteri önizlemeleri veya tema kodunu kontrol ettiğiniz herhangi bir site için uygundur.

add_action( 'template_redirect', 'enforce_site_wide_login' );

function enforce_site_wide_login() {
    // Allow REST API, cron, and login page to remain accessible
    if ( is_user_logged_in() ) {
        return;
    }

    $request_uri = $_SERVER['REQUEST_URI'] ?? '';

    $public_paths = [
        '/wp-login.php',
        '/wp-cron.php',
        '/wp-json/',
        '/?wc-api=',
    ];

    foreach ( $public_paths as $path ) {
        if ( strpos( $request_uri, $path ) !== false ) {
            return;
        }
    }

    wp_safe_redirect( wp_login_url( home_url( $request_uri ) ) );
    exit;
}

wp_redirect() yerine wp_safe_redirect() kullanımına dikkat edin. Güvenli varyant, yönlendirme hedefini güvenilir ana bilgisayarların izin listesine göre doğrulayarak açık yönlendirme güvenlik açıklarını önler — çevrimiçi dolaşan eklentisiz kod parçacıklarının sıklıkla atladığı bir ayrıntı.

Ayrıca $redirect_to parametresinin wp_login_url() işlevine iletildiğine dikkat edin; böylece başarılı bir girişin ardından kullanıcı genel bir panel yerine başlangıçta talep ettiği sayfaya yönlendirilir. Bu, şeffaf kimlik doğrulama kapıları için doğru UX davranışıdır.

Bu yöntemi ne zaman kullanmalı: Tam dosya sistemi erişimine sahip olduğunuz ve yüksek trafikli bir siteye eklenti yükü eklemekten kaçınmak istediğiniz VPS Hosting ortamlarında alt temalar veya zorunlu kullanım eklentileri (wp-content/mu-plugins/) için idealdir.

Yöntem 3: WordPress Yazı ve Sayfa Görünürlük Ayarları

WordPress, yazı başına görünürlük kontrollerini yerel olarak destekler. Bu, site geneli bir çözüm değildir; ancak tüm site yerine yalnızca belirli içeriklerin kapılanması gerektiğinde doğru yaklaşımdır.

Özel görünürlük, bir yazı veya sayfayı yalnızca read_private_posts yetkisine sahip kullanıcılar için erişilebilir kılar — varsayılan olarak Yöneticiler ve Editörler. Aboneler ve kimliği doğrulanmamış ziyaretçiler 404 yanıtı alır.

Parola korumalı görünürlük, WordPress hesabı gerektirmeden herhangi bir ziyaretçiye tek bir paylaşılan parola ile erişim sağlar. Bu, WordPress hesabına sahip olmaması gereken müşterilerle taslak içerik paylaşmak için kullanışlıdır.

Bu Yaklaşımın Sınırlamaları

• Özel yazılar, yetkili kullanıcılar için wp-admin içinde görünmeye devam eder ve bu durum varlıklarını açığa çıkarabilir.
• WordPress REST API, izin yapılandırmanıza bağlı olarak kimliği doğrulanmış API tüketicilerine özel yazıların başlıklarını veya meta verilerini sızdırabilir.
• Kategori ve etiket arşiv sayfaları, bireysel yazılar özel olsa bile kamuya açık kalabilir.

Ara sıra yapılan içerik kapılamanın ötesinde herhangi bir şey için bu yöntem, bağımsız bir erişim kontrolü stratejisi olarak yetersizdir.

Yöntem 4: Rol Tabanlı Erişim Kontrolü için Üyelik Eklentileri

Gereksinim basit bir giriş kapısının ötesine geçerek abonelik katmanlarını, ödeme işlemeyi, içerik damlatmayı ve rol tabanlı erişim kontrolünü kapsadığında, özel bir üyelik eklentisi uygun araçtır.

Önde Gelen Üyelik Eklentilerinin Karşılaştırması

Temel Mimari Değerlendirme

Üyelik eklentileri erişimi WordPress uygulama katmanında zorlar. Doğrudan dosya URL’lerini korumaz. Bir üye PDF indirip URL’yi paylaşırsa, o URL’ye sahip üye olmayan herhangi biri dosyaya erişebilir. Yüklenen medya dosyalarını korumak için, dosya isteklerini PHP aracılığıyla yönlendiren sunucu düzeyinde kurallar gerekir — bu, özel bir Nginx location bloğu veya Apache’de .htaccess yeniden yazma kuralı gerektiren bir yapılandırmadır.

cPanel ile VPS‘te, dosya yöneticisi aracılığıyla veya web sunucusu yapılandırmasına doğrudan erişimle SSH üzerinden korumalı medya dizinlerini yapılandırabilirsiniz.

Yöntem 5: .htaccess Aracılığıyla HTTP Basic Auth (Sunucu Düzeyi)

HTTP Basic Auth, kimlik doğrulamayı WordPress’ten tamamen bağımsız olarak web sunucusu katmanında zorlar. Bu, WordPress uygulamasının kimliği doğrulanmamış istekler için hiçbir zaman çalıştırılmadığı anlamına gelir — bu da onu en kaynak verimli yöntem ve kimliği doğrulanmamış yollarda WordPress düzeyindeki güvenlik açıklarına karşı koruyan tek yöntem yapar.

Bu yöntem, yüksek güvenlikli ortamlarda WordPress kimlik doğrulamasının üzerinde ikincil bir katman olarak veya hazırlık siteleri için bağımsız bir kapı olarak özellikle değerlidir.

Adım 1: .htpasswd Dosyasını Oluşturun

Apache yardımcı programlarının yüklü olduğu bir Linux sunucusunda:

htpasswd -c /etc/apache2/.htpasswd staging_user

-c bayrağı yeni bir dosya oluşturur. Mevcut bir dosyaya sonraki kullanıcıları eklerken bunu atlayın. .htpasswd dosyasını web kökünün dışında saklayın — asla public_html veya www içinde saklamayın.

Nginx sunucuları için süreç aynıdır, çünkü Nginx aynı .htpasswd biçimini okur.

Adım 2: Apache’yi Yapılandırın (.htaccess)

AuthType Basic
AuthName "Restricted — Authorized Access Only"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

Bunu WordPress kökünüzdeki .htaccess dosyasına yerleştirin. Belirli IP adreslerini beyaz listeye almanız gerekiyorsa (örneğin, ofis ağınız istemi atlıyor):

AuthType Basic
AuthName "Restricted — Authorized Access Only"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
Order allow,deny
Allow from 203.0.113.0/24
Satisfy Any

Adım 3: Nginx’i Yapılandırın

Sunucunuz Nginx çalıştırıyorsa — LiteSpeed veya OpenLiteSpeed ile VPS Hosting altyapılarında yaygındır — sitenizin server bloğuna aşağıdakileri ekleyin:

location / {
    auth_basic "Restricted — Authorized Access Only";
    auth_basic_user_file /etc/nginx/.htpasswd;

    # Pass authenticated requests to PHP-FPM
    try_files $uri $uri/ /index.php?$args;
}

# Whitelist specific paths (e.g., payment callbacks)
location /wp-json/payment-gateway/ {
    auth_basic off;
    try_files $uri $uri/ /index.php?$args;
}

Değişikliklerden sonra Nginx’i yeniden yükleyin:

sudo nginx -t && sudo systemctl reload nginx

Kritik Tuzak: WordPress Giriş Döngüsü

HTTP Basic Auth bir WordPress sitesinde etkin olduğunda, WordPress giriş formu kimlik bilgilerini aynı zamanda Basic Auth tarafından korunan wp-login.php adresine gönderir. Tarayıcılar bunu, Basic Auth kimlik bilgilerini form POST’uyla birlikte göndererek doğru şekilde işler; ancak bazı REST API istemcileri ve JavaScript tabanlı giriş akışları başarısız olabilir. Bu yapılandırmayı etkinleştirdikten sonra giriş akışınızı kapsamlı şekilde test edin.

Ayrıca, WooCommerce gibi eklentiler tarafından kullanılan wp-cron.php ve REST API uç noktaları sunucu yapılandırmanızda açıkça beyaz listeye alınmalıdır; aksi takdirde bu entegrasyonlar sessizce bozulacaktır.

Yüklenen Medya Dosyalarını Koruma (Her Kılavuzun Atladığı Boşluk)

Hangi WordPress düzeyinde yöntemi seçerseniz seçin, wp-content/uploads/ içindeki dosyalar doğrudan web sunucusu tarafından sunulur ve PHP tabanlı tüm erişim kontrollerini atlar. Korumalı bir PDF, resim veya videoya doğrudan URL’yi edinen bir kullanıcı, giriş yapmadan erişebilir.

Apache’de bu boşluğu kapatmak için wp-content/uploads/.htaccess dosyasına aşağıdakileri ekleyin:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^(.*)$ /wp-content/plugins/your-protection-plugin/serve-file.php?file=$1 [QSA,L]

Bu, tüm dosya isteklerini dosyayı sunmadan önce WordPress kimlik doğrulamasını doğrulayabilen bir PHP betiği aracılığıyla yönlendirir. Çoğu kurumsal üyelik eklentisi, bu kalıbı uygulayan korumalı bir dosya teslim modülü içerir.

Nginx’te eşdeğer yapılandırma, dosya isteklerini bir PHP işleyicisine fastcgi_pass aracılığıyla yönlendirmeyi gerektirir; bu, sunucu yapılandırma düzeyinde uygulanmalıdır — ciddi üyelik siteleri için VPS Hosting ortamında kök SSH erişiminin neden gerekli olduğunun bir başka nedeni.

Doğru Yöntemi Seçme: Karar Matrisi

SSL ve Alan Adı Değerlendirmeleri

Giriş gerektiren herhangi bir site HTTPS üzerinden çalışmalıdır. WordPress kimlik bilgilerini şifrelenmemiş bir bağlantı üzerinden iletmek, oturum çerezlerini ve parolaları ağ dinlemesine maruz bırakır. Sitenizde henüz geçerli bir sertifika yoksa, herhangi bir giriş zorunluluğu uygulamadan önce bir tane yapılandırın.

SSL Sertifikaları, kimliği doğrulanmış herhangi bir WordPress dağıtımı için isteğe bağlı bir geliştirme değil, bir ön koşuldur. Modern tarayıcılar, HTTP üzerinden sunulan giriş formlarında güvenlik uyarıları gösterecek ve WordPress’in kendisi bunu yönetici panelinde işaretleyecektir.

Sıfırdan yeni bir özel WordPress sitesi kuruyorsanız, Alan Adı Kaydı aracılığıyla özel bir alan adı kaydettirmek ve bunu uygun bir SSL sertifikasıyla eşleştirmek, kimlik doğrulama katmanının ilk günden itibaren güvenli bir temele oturtulmasını sağlar.

Pratik Temel Kontrol Listesi

Herhangi bir giriş zorunluluğu uygulamasıyla yayına geçmeden önce aşağıdakilerin her birini doğrulayın:

• Giriş sayfası erişilebilir. wp-login.php ve /wp-admin/ adreslerinin zorunluluk kodunuz veya sunucu kurallarınız tarafından yanlışlıkla engellenmediğini onaylayın.
• REST API uç noktaları denetlendi. Hangi REST rotalarının kamuya açık kalması gerektiğini (ödeme geri aramaları, uygulama entegrasyonları) belirleyin ve bunları açıkça beyaz listeye alın.
• wp-cron.php engellenmedi. Cron istekleri giriş zorunluluğu tarafından kesilirse zamanlanmış görevler sessizce başarısız olacaktır.
• Yüklenen medya korundu. Siteniz hassas dosyalar sunuyorsa, PHP aracılığıyla sunucu düzeyinde dosya yönlendirmesi uygulayın — yalnızca WordPress düzeyinde erişim kontrolüne güvenmeyin.
• HTTPS zorlandı. Giriş kapısı etkinleşmeden önce tüm HTTP trafiğini HTTPS’ye yönlendirin.
• Giriş sonrası yönlendirme test edildi. Özellikle giriş yapmadan önce derin bir bağlantıya erişirken kullanıcıların kimlik doğrulamasının ardından doğru sayfaya yönlendirildiğini doğrulayın.
• Parola sıfırlama akışı çalışıyor. wp-login.php?action=lostpassword yolu kimliği doğrulanmamış kullanıcılar için erişilebilir kalmalıdır.
• XML-RPC değerlendirildi. XML-RPC kullanmıyorsanız devre dışı bırakın. Kullanıyorsanız, giriş zorunluluğunuzun onu engellemediğinden emin olun.
• Hazırlık ve üretim paritesi. Hazırlıkta .htaccess Basic Auth kullanıyorsanız, üretime dağıtmadan önce kaldırıldığından veya değiştirildiğinden emin olun.

SSS

WordPress girişini zorlamak SEO’yu etkiler mi?

Evet, önemli ölçüde. Arama motoru tarayıcıları WordPress giriş formları aracılığıyla kimlik doğrulayamaz, bu nedenle tamamen kapılı bir site dizine eklenmez. Kamuya açık keşfedilebilirlik bir hedefse, site geneli giriş zorunluluğu yerine seçici içerik kısıtlaması kullanın. Tamamen özel siteler için bu amaçlanan davranıştır.

Force Login eklentisi WordPress REST API’sini engeller mi?

Kevin Vess tarafından geliştirilen Force Login eklentisi, son sürümlerde varsayılan olarak REST API isteklerini engellemez — zorunluluğu yalnızca ön uç şablon işlemeye uygular. Ancak, kimliği doğrulanmamış REST API istekleri, rest_authentication_errors filtresi veya özel bir API kimlik doğrulama eklentisi kullanarak REST API erişimini ayrıca kısıtlamadığınız sürece veri döndürmeye devam edecektir.

Çok siteli bir ağda eklenti olmadan giriş zorlaması yapabilir miyim?

Evet, ancak functions.php kancası, tek bir sitenin tema dosyası yerine ağ genelinde etkinleştirilmiş bir eklentiye veya wp-content/mu-plugins/ dizinine yerleştirilmelidir. Tema düzeyindeki kod yalnızca o temayı kullanan siteye uygulanır, tüm ağa değil.

Site geneli giriş zorunluluğu uygulandığında WooCommerce ödeme sayfalarına ne olur?

WooCommerce ödeme, sepet, hesap kaydı ve ödeme ağ geçidi geri arama URL’leri, zorunluluk kodunuzda açıkça beyaz listeye alınmalıdır. Bunu yapmamak, müşterileri ödeme akışından uzaklaştırarak tüm satın almaları bozacaktır. Bir WooCommerce sitesinde giriş zorunluluğunu etkinleştirdikten sonra her zaman tam satın alma akışını test edin.

HTTP Basic Auth, bir WordPress sitesi için tek güvenlik katmanı olarak yeterli midir?

Hayır. HTTP Basic Auth, kimliği doğrulanmamış erişime karşı koruma sağlar, ancak kimlik bilgilerini Base64 kodlamasıyla iletir; bu, şifrelenmemiş bir bağlantıda ele geçirilirse kolayca çözülür. Her zaman HTTPS üzerinden kullanılmalıdır. Ayrıca, WordPress düzeyinde kimlik doğrulamanın sağladığı oturum yönetimi, denetim günlüğü veya rol tabanlı erişim kontrolü yetenekleri sunmaz. Basic Auth’u uygun WordPress kimlik doğrulamasının yerine değil, tamamlayıcı bir katman olarak kullanın.