Tôi thường sử dụng đối số này để ngăn ngừa lỗi với wp_remote_getvàwp_remote_post
array(
'sslverify' => false
)
Vì lý do bảo mật, tôi muốn đặt nó thành true(hoặc xóa nó vì mặc định là đúng).
Tôi có nên mong đợi bất kỳ vấn đề bằng cách làm điều đó?
Câu trả lời:
TL; DR: Có, xóa cài đặt đó kể từ WordPress 3.7 trở lên.
Trước đây, nhiều người đã thêm tham số sslverify = false vì cài đặt PHP của họ không thể xác minh đúng chứng chỉ.
Thông thường, điều này là do cài đặt PHP chưa được cập nhật với bản sao Chứng chỉ gốc CA mới nhất. Các certs gốc thay đổi thường xuyên và thông thường bạn không nhận thấy sự thay đổi này vì nó xảy ra trong các bản cập nhật trình duyệt thông thường. Chà, khi bạn có PHP hoạt động như một trình duyệt để truy xuất các url https, thì nó cũng cần những cập nhật chứng chỉ gốc. Và hầu hết các máy chủ không bao giờ cập nhật PHP, cũng không cập nhật bất kỳ phần cụ thể nào của nó (như tệp chứng chỉ).
Khi WordPress triển khai tự động cập nhật trong phiên bản 3.7, cần phải nâng cấp API WordPress.org để yêu cầu giao tiếp an toàn. Tại thời điểm này, WordPress đã bắt đầu bao gồm một bản sao của tệp Chứng chỉ gốc CA, có nguồn gốc từ Mozilla. Do đó, vì WordPress 3.7, các hàm API WP_HTTP sử dụng tệp này để xác minh chứng chỉ và không phải bất kỳ phiên bản cũ hoặc lỗi thời nào được đóng gói với cài đặt PHP của bạn.
Do đó, có, với WordPress 3.7 trở lên, nên xóa tham số sslverify và cho phép các hàm http thực hiện xác minh chứng chỉ phù hợp. Bất kỳ máy chủ hiện đại nào chạy SSL có khóa được ký bởi một trong các CA đã biết sẽ được xác minh đúng. WP_HTTP nên có một bản sao các chứng chỉ gốc mới nhất và dự án cốt lõi sẽ cập nhật tệp chứng chỉ đó trong WordPress cùng với các bản cập nhật thông thường.
Có rất nhiều lý do có thể khiến việc xác minh SSL thất bại. Bắt đầu từ quá nhiều chuyển hướng đến .inicác tệp / thiết lập sai hoặc đơn giản là thiếu chứng chỉ hoặc tên miền phụ. Trong mọi trường hợp, bạn sẽ cần tìm kiếm lý do cho điều đó và khắc phục nó . Không có cách nào xung quanh nó.
Nhưng để tạm thời khắc phục sự cố đó (giả sử bạn cần phát triển mã của mình hơn nữa và khắc phục lỗi SSL sau này), bạn có thể sử dụng bộ lọc:
add_filter( 'https_ssl_verify', '__return_false' );Khi bạn đang chạy ứng dụng này trong một yêu cầu từ xa, bạn nên bọc nó trong một cuộc gọi lại được gắn vào bộ lọc được kích hoạt trong khi yêu cầu HTTP như vậy. Đảm bảo kiểm tra xem bạn có thực sự xóa xác minh cho trường hợp chính xác không - và đảm bảo rằng bạn chỉ chạy cái này một lần để không bảo đảm các yêu cầu khác.
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 );Nếu đây là một plugin được phân phối công khai, thì bạn có thể muốn đính kèm nó vào một tùy chọn đơn giản mà người dùng có thể bật hoặc tắt. Bạn cũng có thể thử yêu cầu đã được xác minh trước và nếu không (và nếu người dùng đã chọn tham gia yêu cầu chưa được ký), thì hãy chuyển sang yêu cầu có khả năng không an toàn.
Quy tắc của ngón tay cái:
Không bao giờ thực hiện một yêu cầu không an toàn cho đến khi người dùng của bạn đồng ý thực hiện và biết về các rủi ro.
WordPress có thể dựa vào phần mềm máy chủ cơ bản (thường là cURL) để thực hiện yêu cầu mạng. Tóm lại bởi vì đó là những gì phần mềm đó là tốt và có cho.
Trên một số máy chủ vì nhiều lý do (tôi chưa bao giờ bận tâm đến bản thân mình), điều khá điển hình là phần mềm máy chủ không thể "xác minh" các kết nối an toàn, tạo ra các lỗi đã nói.
Vì thế: