TL; DR: Да, удалите эту настройку с WordPress 3.7 или более поздней версии.
В прошлом многие люди добавляли параметр sslverify = false специально, потому что их установка PHP не смогла правильно проверить сертификат.
Как правило, это происходит потому, что установка PHP не была обновлена последней копией корневых сертификатов CA. Корневые сертификаты меняются очень часто, и обычно вы не замечаете это изменение, потому что оно происходит в обычных обновлениях браузера. Что ж, если у вас PHP, действующий как браузер для получения URL-адресов https, ему также нужны эти обновления корневых сертификатов. И большинство хостов никогда не обновляют PHP и не обновляют какую-либо его часть (например, файл сертификатов).
Когда WordPress реализовал автообновление в версии 3.7, было решено, что необходимо обновить API WordPress.org, чтобы обеспечить безопасную связь. В это время WordPress начал включать в себя копию самого файла CA Root Certificates, полученного из Mozilla. Начиная с WordPress 3.7, функции API WP_HTTP используют этот файл для проверки сертификата, а не какую-либо старую или устаревшую версию, поставляемую с вашей установкой PHP.
Поэтому да, в WordPress 3.7 или более поздней версии рекомендуется удалить параметр sslverify и разрешить функциям http выполнять надлежащую проверку сертификата. Любой современный сервер, использующий SSL с ключом, подписанным одним из известных ЦС, будет проверен должным образом. WP_HTTP должен иметь копию последних корневых сертификатов, и основной проект обновит этот файл сертификатов в WordPress вместе с обычными обновлениями.
Спасибо Отто, я думаю, что это очень помогает. Я сделаю некоторую условную проверку в своем плагине
Xaver
9
Существует множество причин, по которым проверка 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: abortif('foo'!== $params['foo'])return $params;
add_filter('https_ssl_verify','__return_false');return $params;},10,2);
Если это общедоступный плагин, вы можете присоединить его к простой опции, которую пользователь может включить или отключить. Вы также можете сначала попробовать проверенный запрос, а если нет (и если пользователь выбрал неподписанный запрос), то переключиться на потенциально небезопасный запрос.
Практическое правило:
Никогда не выполняйте небезопасный запрос, пока ваш пользователь не согласится на это и не узнает о рисках.
Спасибо, я сейчас ищу проблему в моей местной среде
Xaver
4
WordPress может использовать программное обеспечение сервера (обычно cURL) для выполнения сетевого запроса. В двух словах, потому что это то, что это программное обеспечение хорошо и для чего.
На некоторых серверах по разным причинам (я никогда не удосужился заглянуть в себя) для серверного программного обеспечения довольно типично не иметь возможности «проверять» безопасные соединения, вызывая указанные ошибки.
Так:
если это приватный код на серверах, которые вы контролируете, убедитесь, что серверы правильно отправляют запросы, и этот параметр не отключен
если это код для публичного распространения, вы, вероятно, тоже не хотите его отключать, но если он достаточно популярен, он попадет на серверы, где он в какой-то момент сломан, и вам придется поддерживать это в какой-то форме (из сообщения ожидается, что правильная конфигурация обеспечит настройку его отключения для ваших запросов и т. д.)
Существует множество причин, по которым проверка SSL может быть неудачной. Начиная со слишком большого количества перенаправлений в неправильные
.iniфайлы / настройки или просто пропуская сертификаты или поддоменов. В любом случае вам нужно будет найти причину и устранить ее . Обойти это невозможно .Но чтобы временно обойти эту проблему (допустим, вам нужно продолжить разработку кода и исправить ошибку SSL позже), вы можете использовать фильтр:
Поскольку вы выполняете это во время удаленного запроса, вы должны заключить его в обратный вызов, присоединенный к фильтру, который срабатывает во время такого HTTP-запроса. Обязательно проверьте, действительно ли вы удаляете подтверждение для правильного случая, и убедитесь, что вы запускаете его только один раз, чтобы не обезопасить другие запросы.
Если это общедоступный плагин, вы можете присоединить его к простой опции, которую пользователь может включить или отключить. Вы также можете сначала попробовать проверенный запрос, а если нет (и если пользователь выбрал неподписанный запрос), то переключиться на потенциально небезопасный запрос.
источник
WordPress может использовать программное обеспечение сервера (обычно cURL) для выполнения сетевого запроса. В двух словах, потому что это то, что это программное обеспечение хорошо и для чего.
На некоторых серверах по разным причинам (я никогда не удосужился заглянуть в себя) для серверного программного обеспечения довольно типично не иметь возможности «проверять» безопасные соединения, вызывая указанные ошибки.
Так:
источник