問題描述

我通常使用此引數來防止 wp_remote_get 和 wp_remote_post 發生錯誤

array(
    'sslverify' => false
)

出於安全考慮，我想將其設定為 true(或者從預設值為 true 時將其刪除) 。

我應該期待這樣做有什麼問題嗎？

最佳解決方案

長話短說：是的，從 WordPress 3.7 或更高版本中刪除該設定。

過去許多人特別新增了 sslverify = false 引數，因為它們的安裝 PHP 無法正確驗證證書。

通常，這是因為沒有使用 CA 根證書的最新副本更新 PHP 安裝。根證書每隔一段時間更改一次，通常您不會注意到此更改，因為它會在正常的瀏覽器更新中發生。那麼當你的 PHP 像瀏覽器一樣檢索 https url，那麼它也需要這些根證書更新。大多數主機從不更新 PHP，也不會更新其任何特定部分 (如證書檔案) 。

當 WordPress 在 3.7 版中實現 auto-updating 時，確定需要升級 WordPress.org API 才能要求安全通訊。此時，WordPress 開始包含源自 Mozilla 的 CA 根證書檔案本身的副本。因此，由於 WordPress 3.7，因此 WP_HTTP API 函式使用此檔案進行證書驗證，而不是任何舊版或過時的版本與您的 PHP 安裝一起打包。

因此，是的，使用 WordPress 3.7 或更高版本，建議刪除 sslverify 引數並允許 http 功能進行正確的證書驗證。任何執行 SSL 的現代伺服器都會使用已知 CA 之一簽名的金鑰進行正確驗證。 WP_HTTP 應具有最新根證書的副本，核心專案將隨著正常更新一起更新 WordPress 中的證書檔案。

次佳解決方案

有許多原因可以讓 SSL 驗證失敗。從太多重定向到錯誤的.ini 檔案/設定或簡單地缺少證書或子域。無論如何，您將需要搜尋原因並進行修復。沒有辦法。

但是要臨時解決這個問題 (假設您需要進一步開發程式碼並稍後修復 SSL 錯誤)，可以使用過濾器：

add_filter( 'https_ssl_verify', '__return_false' );

當您在遠端請求期間執行此應用程式時，應將其包裝在附加到在此類 HTTP 請求期間觸發的過濾器的回撥中。確保檢查您是否正在刪除正確案例的驗證，並確保只執行一次，以不解除其他請求。

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 );

如果這是一個公開分發的外掛，那麼您可能希望將其附加到使用者可以開啟或關閉的簡單選項。您也可以首先嚐試驗證的請求，如果沒有 (如果使用者已經選擇了未簽名的請求)，則切換到潛在的不安全請求。

Rule of thumb:

Do never perform an unsecure request until your user has agreed to do so and knows of the risks.

第三種解決方案

WordPress 可以依靠底層伺服器軟體 (通常是 cURL) 來執行網路請求。簡而言之，因為它是什麼軟體是好的，在那裡。

在某些伺服器上，由於各種原因 (我從來沒有打擾過我自己)，伺服器軟體無法使用”verify” 安全連線是非常典型的，從而產生錯誤。

所以：

  • 如果這是您控制的伺服器上的專用程式碼，您應該確保伺服器正在正確提出請求，並且此設定不被停用

  • 如果這是公共發行的程式碼，你可能不想停用它，但是如果它很受歡迎，它將在某個時候被破壞的伺服器上結束，你必須以某種形式 (從告訴人們預期適當的配置可以為您的請求提供停用設定，等等)

參考文獻

注：本文內容整合自 Google/Baidu/Bing 輔助翻譯的英文資料結果。如果您對結果不滿意，可以加入我們改善翻譯效果：薇曉朵技術論壇。