Normalmente uso questo argomento per prevenire errori con wp_remote_getewp_remote_post
array(
'sslverify' => false
)Per motivi di sicurezza, vorrei impostarlo su true(o rimuoverlo poiché l'impostazione predefinita è vera).
Dovrei aspettarmi problemi facendo questo?
Risposte:
TL; DR: Sì, rimuovi tale impostazione a partire da WordPress 3.7 o successivo.
In passato, molte persone hanno aggiunto il parametro sslverify = false proprio perché la loro installazione di PHP non è stata in grado di verificare correttamente il certificato.
In genere, ciò era dovuto al fatto che l'installazione di PHP non era stata aggiornata con l'ultima copia dei certificati radice CA. I certificati root cambiano ogni tanto e normalmente non si nota questa modifica perché si verifica nei normali aggiornamenti del browser. Bene, quando PHP si comporta come un browser per recuperare gli URL https, allora ha bisogno anche di quegli aggiornamenti del certificato di root. E la maggior parte degli host non aggiorna mai PHP, né aggiorna alcuna parte specifica di esso (come il file dei certificati).
Quando WordPress ha implementato l'aggiornamento automatico nella versione 3.7, è stato determinato che era necessario aggiornare le API di WordPress.org per richiedere comunicazioni sicure. A quel tempo, WordPress iniziò a includere una copia del file dei certificati di root CA stesso, proveniente da Mozilla. A partire da WordPress 3.7, quindi, le funzioni dell'API WP_HTTP utilizzano questo file per eseguire la verifica del certificato e non qualsiasi versione precedente o obsoleta sia inclusa nell'installazione di PHP.
Pertanto, sì, con WordPress 3.7 o versioni successive, è consigliabile rimuovere il parametro sslverify e consentire alle funzioni http di eseguire la verifica del certificato corretta. Qualsiasi server moderno che esegue SSL con una chiave firmata da una delle CA note verrà verificato correttamente. WP_HTTP dovrebbe avere una copia degli ultimi certificati root e il progetto principale aggiornerà quel file di certificati in WordPress insieme ai normali aggiornamenti.
Esistono molte ragioni per cui la verifica SSL non riesce. A partire da troppi reindirizzamenti a .inifile / configurazioni errati o semplicemente certificati o sottodomini mancanti. In ogni caso, dovrai cercare il motivo e risolverlo . Non c'è modo di aggirarlo.
Ma per risolvere temporaneamente questo problema (supponiamo che sia necessario sviluppare ulteriormente il codice e correggere l'errore SSL in un secondo momento), è possibile utilizzare un filtro:
add_filter( 'https_ssl_verify', '__return_false' );Mentre lo stai eseguendo durante una richiesta remota, dovresti racchiuderlo in un callback collegato a un filtro che viene attivato durante tale richiesta HTTP. Assicurati di verificare se stai davvero rimuovendo la verifica per il caso corretto e assicurati di eseguirlo solo una volta per non rendere sicure altre richieste.
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 );Se si tratta di un plug-in distribuito pubblicamente, è possibile collegarlo a una semplice opzione che l'utente può attivare o disattivare. Puoi anche provare prima la richiesta verificata e, in caso contrario (e se l'utente ha optato per una richiesta non firmata), passa a una richiesta potenzialmente non sicura.
Regola del pollice:
Non eseguire mai una richiesta non sicura fino a quando l'utente non ha accettato di farlo e non è a conoscenza dei rischi.
WordPress può fare affidamento sul software server sottostante (in genere cURL) per eseguire richieste di rete. In poche parole perché è quello che quel software è buono ed è lì per.
Su alcuni server per vari motivi (non mi ero mai preso la briga di guardarmi dentro) è abbastanza tipico che il software server non sia in grado di "verificare" connessioni sicure, producendo detti errori.
Così: