Я обычно использую этот аргумент для предотвращения ошибок wp_remote_getиwp_remote_post
array(
'sslverify' => false
)Из соображений безопасности я хотел бы установить его true(или удалить, поскольку по умолчанию установлено значение true).
Стоит ли ожидать от этого каких-либо проблем?
Ответы:
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 вместе с обычными обновлениями.
Существует множество причин, по которым проверка 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 );Если это общедоступный плагин, вы можете присоединить его к простой опции, которую пользователь может включить или отключить. Вы также можете сначала попробовать проверенный запрос, а если нет (и если пользователь выбрал неподписанный запрос), то переключиться на потенциально небезопасный запрос.
Практическое правило:
Никогда не выполняйте небезопасный запрос, пока ваш пользователь не согласится на это и не узнает о рисках.
WordPress может использовать программное обеспечение сервера (обычно cURL) для выполнения сетевого запроса. В двух словах, потому что это то, что это программное обеспечение хорошо и для чего.
На некоторых серверах по разным причинам (я никогда не удосужился заглянуть в себя) для серверного программного обеспечения довольно типично не иметь возможности «проверять» безопасные соединения, вызывая указанные ошибки.
Так: