After a server upgrade to PHP 5.6, SOAP no longer works for me with an https connection. I'm unclear of exactly why but after a bit of digging around, the solution that got it working again was to add a stream context to the options when creating the SOAPClient in wsclient_soap.module:
class WSClientSOAPEndpoint extends WSClientEndpoint {
public function client() {
if (!isset($this->client)) {
$options['exceptions'] = TRUE;
// We need to handle different ciphers for PHP 5.6
//@$endpoint = new SOAPClient($form_state['values']['url']);
$options['stream_context'] = stream_context_create(
array(
'ssl' => array(
'verify_peer' => false,
'verify_peer_name' => false
)
)
);
...and...
function wsclient_soap_wsclient_service_form_validate($form, $form_state) {
$service = $form_state['wsclient_service'];
if ($form_state['values']['type'] == 'soap') {
// The url has to point to a valid WSDL file.
try {
// If initializing the SOAPClient succeeds we're good, otherwise we catch
// the exception below and suppress any further warnings.
// WARNING: if you have the xdebug PHP module enabled this can cause a
// fatal error on invalid WSDL files (instead of a catchable SoapFault
// exception).
// xdebug_disable();
@$endpoint = new SOAPClient($form_state['values']['url'],
array(
'stream_context' => stream_context_create(
array(
'ssl' => array(
'verify_peer' => false,
'verify_peer_name' => false
)
)
)
)
);
}
I doubt this is an appropriate long term solution (even if the code checked for an SSL connection and PHP 5.6). Any thoughts on the best way to implement this?
Comments
Comment #2
danwonac commentedComment #3
danwonac commentedComment #4
danwonac commentedComment #5
dman commentedI know SSL can be a pain to work with ... but I think the idea is that verification errors are something that needs to be fixed *somewhere* at one end or the other of the transaction.
I can't help feeling that just turning verifications off defeats the point of SSL in general.
Whenever we hit a browser warning and "Proceed anyway" or I have to download a patch using "--no-check-certificate" ... I think something is wrong in the world. Unfortunately, the fix for that something is seldom simple, and half the time out of our control.
It could be you are dealing with an SSL "Self Signed Certificate", which (I think) means your transaction is *encrypted* but the endpoint is not necessarily verified or to be trusted.
It's handy to skip the name verification in this case, I know, but if we have to do this - it's gonna be an (off by default) configurable option.
Comment #6
danwonac commentedYou're absolutely right of course @dman, this really isn't an appropriate fix. I had to do something to address my connectivity issues immediately on a live site. It didn't dawn on me that the certificate was self-signed, I was thinking solution rather than cause at the time. I've changed the title to something more appropriate.
In my particular circumstance, the certificate is fine as self-signed (I believe...), it's not public facing, fixed IP and requires a login.
Having had a bit of time to think about it I wonder if a 'Verify Peer' checkbox in the web service description screen might be an appropriate way to go?
Comment #7
danwonac commentedComment #8
dman commented> In my particular circumstance, the certificate is fine as self-signed (I believe...), it's not public facing, fixed IP and requires a login.
Yep, that's pretty common for internal services.
> Having had a bit of time to think about it I wonder if a 'Verify Peer' checkbox in the web service description screen might be an appropriate way to go?
Yep, that's where we would have to do it. Next to the endpoint URI I guess
Comment #9
satishb commented@$endpoint = new SOAPClient($form_state['values']['url'],
array(
'stream_context' => stream_context_create(
array(
'ssl' => array(
'verify_peer' => false,
'verify_peer_name' => false
)
)
)
)
);
adding the parameters on php 5.6 call worked for me ,works like before.
http://php.net/manual/en/migration56.openssl.php