Saya biasanya menggunakan argumen ini untuk mencegah kesalahan dengan wp_remote_getdanwp_remote_post
array(
'sslverify' => false
)Untuk alasan keamanan, saya ingin mengaturnya true(atau menghapusnya karena defaultnya benar).
Haruskah saya mengharapkan masalah dengan melakukan itu?
Jawaban:
TL; DR: Ya, hapus pengaturan itu pada WordPress 3.7 atau yang lebih baru.
Di masa lalu, banyak orang menambahkan sslverify = parameter palsu khusus karena pemasangan PHP mereka tidak dapat memverifikasi sertifikat dengan benar.
Biasanya, ini karena pemasangan PHP belum diperbarui dengan salinan CA Root Certificates terbaru. Sertifikat root sering berubah, dan biasanya Anda tidak melihat perubahan ini karena ini terjadi pada pembaruan peramban normal. Nah, ketika Anda memiliki PHP yang bertindak seperti browser untuk mengambil https url, maka diperlukan pembaruan sertifikat root tersebut juga. Dan sebagian besar host tidak pernah memperbarui PHP, atau memperbarui bagian tertentu apa pun darinya (seperti file sertifikat).
Ketika WordPress menerapkan pembaruan otomatis dalam versi 3.7, ditentukan bahwa perlu untuk meningkatkan API WordPress.org untuk memerlukan komunikasi yang aman. Pada saat ini, WordPress mulai memasukkan salinan file CA Root Certificates itu sendiri, yang bersumber dari Mozilla. Karena WordPress 3.7, oleh karena itu, fungsi WP_HTTP API menggunakan file ini untuk melakukan verifikasi sertifikat, dan bukan versi lama atau lama apa pun yang dikemas dengan instalasi PHP Anda.
Oleh karena itu, ya, dengan WordPress 3.7 atau lebih baru, disarankan untuk menghapus parameter sslverify dan memungkinkan fungsi http untuk melakukan verifikasi sertifikat yang tepat. Server modern mana pun yang menjalankan SSL dengan kunci yang ditandatangani oleh salah satu CA yang dikenal akan diverifikasi dengan benar. WP_HTTP harus memiliki salinan sertifikat root terbaru, dan proyek inti akan memperbarui file sertifikat itu di WordPress bersama dengan pembaruan normal.
Ada banyak alasan yang dapat membuat verifikasi SSL gagal. Mulai dari terlalu banyak pengalihan ke .inifile / setup yang salah atau hanya hilang sertifikat atau sub domain. Bagaimanapun, Anda perlu mencari alasan untuk itu dan memperbaikinya . Tidak ada jalan lain.
Tetapi untuk sementara waktu mengatasi masalah itu (katakanlah Anda perlu mengembangkan kode Anda lebih lanjut dan memperbaiki kesalahan SSL nanti), Anda dapat menggunakan filter:
add_filter( 'https_ssl_verify', '__return_false' );Saat Anda menjalankan ini selama permintaan jarak jauh, Anda harus membungkusnya dalam panggilan balik yang terpasang ke filter yang dipicu selama permintaan HTTP tersebut. Pastikan untuk memeriksa apakah Anda benar-benar menghapus verifikasi untuk kasus yang benar - dan pastikan Anda hanya menjalankan ini sekali untuk tidak mengamankan permintaan lainnya.
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 );Jika ini adalah plugin yang didistribusikan secara publik, maka Anda mungkin ingin melampirkannya ke opsi sederhana yang dapat dihidupkan atau dimatikan pengguna. Anda juga dapat mencoba permintaan yang diverifikasi terlebih dahulu dan jika tidak (dan jika pengguna telah memilih untuk permintaan yang tidak ditandatangani), kemudian beralih ke permintaan yang berpotensi tidak aman.
Aturan praktis:
Jangan pernah melakukan permintaan yang tidak aman sampai pengguna Anda telah setuju untuk melakukannya dan mengetahui risikonya.
WordPress dapat mengandalkan perangkat lunak server yang mendasarinya (biasanya cURL) untuk melakukan permintaan jaringan. Singkatnya karena itu adalah apa perangkat lunak itu baik dan ada untuk
Pada beberapa server karena berbagai alasan (saya tidak pernah repot-repot melihat ke dalam diri saya) itu cukup khas untuk perangkat lunak server untuk tidak dapat "memverifikasi" koneksi aman, menghasilkan kesalahan kata.
Begitu: