Normalde bu bağımsız değişkeni wp_remote_getvewp_remote_post
array(
'sslverify' => false
)Güvenlik nedenleriyle bunu ayarlamak istiyorum true(veya varsayılan doğru olduğu için kaldırmak istiyorum).
Bunu yaparak herhangi bir sorun beklemeli miyim?
Yanıtlar:
TL; DR: Evet, bu ayarı WordPress 3.7 veya sonraki sürümlerden kaldırın.
Geçmişte, birçok kişi sslverify = false parametresini özellikle PHP yüklemeleri sertifikayı doğru bir şekilde doğrulayamadığı için ekledi.
Tipik olarak, bunun nedeni PHP kurulumunun CA Kök Sertifikalarının en son kopyasıyla güncellenmemiş olmasıdır. Kök sertifikaları çok sık değişir ve normalde bu değişikliği normal tarayıcı güncellemelerinde gerçekleştiği için fark etmezsiniz. Peki, https URL'lerini almak için bir tarayıcı gibi davranan PHP'niz varsa, o da bu kök sertifika güncellemelerine ihtiyaç duyar. Ve çoğu ana bilgisayar PHP'yi hiçbir zaman güncellemez veya bunun belirli bir bölümünü (sertifika dosyası gibi) güncellemez.
WordPress, 3.7 sürümünde otomatik güncellemeyi uyguladığında, güvenli iletişim gerektirecek şekilde WordPress.org API'lerini yükseltmenin gerekli olduğu belirlenmiştir. Şu anda, WordPress, Mozilla'dan kaynaklanan CA Kök Sertifikaları dosyasının bir kopyasını dahil etmeye başladı. Bu nedenle, WordPress 3.7'den bu yana, WP_HTTP API işlevleri PHP yüklemenizle birlikte gelen eski veya güncel olmayan sürümleri değil, sertifika doğrulaması yapmak için bu dosyayı kullanır.
Bu nedenle, evet, WordPress 3.7 veya üstü ile sslverify parametresini kaldırmanız ve http işlevlerinin uygun sertifika doğrulaması yapmasına izin vermeniz önerilir. Bilinen CA'lardan biri tarafından imzalanmış bir anahtarla SSL çalıştıran tüm modern sunucular düzgün bir şekilde doğrulanacaktır. WP_HTTP, en son kök sertifikaların bir kopyasına sahip olmalıdır ve çekirdek proje, bu güncelleştirmelerle birlikte WordPress'teki sertifika dosyasını güncelleştirir.
SSL doğrulamasının başarısız olmasına neden olabilecek birçok neden vardır. Çok fazla yönlendirmeden yanlış .inidosyalara / kurulumlara veya eksik sertifikaları veya alt alan adlarını kullanmaya başlamak . Her durumda, bunun nedenini araştırmanız ve düzeltmeniz gerekecektir . Orada hiçbir etrafında yol.
Ancak geçici olarak bu soruna geçici bir çözüm bulmak için (diyelim ki kodunuzu daha da geliştirmeniz ve SSL hatasını daha sonra düzeltmeniz gerekiyor), bir filtre kullanabilirsiniz:
add_filter( 'https_ssl_verify', '__return_false' );Bunu uzak bir istek sırasında çalıştırırken, bu tür bir HTTP isteği sırasında tetiklenen bir filtreye eklenmiş bir geri aramaya sarmalısınız. Doğru durum için doğrulamayı gerçekten kaldırıp kaldırmadığınızı kontrol edin ve diğer istekleri güvenli hale getirmek için bunu yalnızca bir kez çalıştırdığınızdan emin olun.
add_filter( 'http_request_args', function( $params, $url )
{
// find out if this is the request you are targeting and if not: abort
if ( 'foo' !== $params['foo'] )
return $params;
add_filter( 'https_ssl_verify', '__return_false' );
return $params;
}, 10, 2 );Bu, genel olarak dağıtılmış bir eklentiyse, bunu kullanıcının açıp kapatabileceği basit bir seçeneğe eklemek isteyebilirsiniz. Önce doğrulanmış isteği de deneyebilirsiniz ve eğer değilse (ve kullanıcı imzalanmamış bir istekte bulunmayı seçtiyse), güvenli olmayabilecek bir isteğe geçebilirsiniz.
Temel kural:
Do asla kullanıcı bunu kabul etti ve risklerin bilir kadar güvensiz bir isteği gerçekleştirmek.
WordPress, ağ isteği gerçekleştirmek için temel sunucu yazılımına (genellikle cURL) güvenebilir. Özetle, bu yazılımın iyi olduğu ve orada olduğu için.
Çeşitli nedenlerden dolayı bazı sunucularda (kendime bakmayı hiç rahatsız etmedim) sunucu yazılımının, söz konusu hataları üreten güvenli bağlantıları "doğrulayamaması" oldukça tipiktir.
Yani: