Jump to content

Recommended Posts

Hey, 'all. I think I'm just tired because I can't see the issue here, but I'm trying to run a SOAP 1.2 call to a legit endpoint using a legit function call and getting nothing but a 'Could not connect to host' message with a fault code of 'HTTP'.

Here's some code:

class Testing{
	private $_user = "username";
	private $_pass = "password";
	private $_system = 1;
	private $_uri = "http://legit.com/endpoint/";
	private $_location = "givenlocation.asmx";
	private $_soapClient;
	
	public function __construct(){
		$this->_soapClient = new SoapClient(null, [
			'location' => "{$this->_uri}{$this->_location}",
			'uri' => $this->_uri,
			'soap_version' => SOAP_1_2,
			'exceptions' => true,
			'trace' => true,
		]);
	}
	
	public function makeCall(){
		try{
			$data = $this->_soapClient->__soapCall('functionCall', [
				'username' => $this->_user,
				'password' => $this->_pass,
			]);
		}catch(SoapFault $e){
			die("<pre>".var_export($e, true)."</pre>");
		}
	}
}


$testSoap = new Testing();
$testSoap->makeCall();

I'll happily take a "Let me Google that for you" result link if it's that simple, but I'm just not seeing the problem. Anybody?

As always, help is greatly appreciated.

 

Forgot to mention - I don't get an error on instantiation of the SoapClient() object, just the __soapCall() call.

Edited by maxxd
7 hours ago, requinix said:

What happens if you go to http://legit.com/endpoint/givenlocation.asmx manually? Errors? Redirect?

From the office system it works fine when the username/password is appended to the URL. I'm wondering if there was a snafu in the IP whitelist where our office was whitelisted correctly but the development system wasn't. I've got an email in with the provider to find out, just wanted to post here in case there was something glaringly obvious that I just yawned over...

I've gotten the connection issues taken care of (as far as I can tell, it was a typo in the IP whitelist).

However, I've got another "am I just totally asleep?" question. The endpoint expects these headers:

POST /path/handler.asmx HTTP/1.1
Host: legit.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://givenNamespace.com/functionCall"
Content-Length: 540

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
	<soap:Body>
		<functionCall xmlns="http://givenNamespace.com">
			<username>username</user>
			<password>password</pwd>
		</functionName>
	</soap:Body>
</soap:Envelope>

and this is what I get from __getLastRequestHeaders() and __getLastRequest() after my __soapCall() call:

POST /path/handler.asmx HTTP/1.1
Host: legit.com
Connection: Keep-Alive
User-Agent: PHP-SOAP/7.2.19
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://givenNamespace.com/functionCall"
Content-Length: 540

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
	<SOAP-ENV:Body>
		<functionCall xsi:type="SOAP-ENC:Struct">
			<username xsi:type="xsd:string">username</user>
			<password xsi:type="xsd:string">password</pwd>
		</functionName>
	</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

It's been a while since I've dealt with a non-WSDL API endpoint but am I crazy that my headers should work? Because I'm getting the following error:

"Server was unable to process request. ---> Handler.loginNoSession(): DB Exception: Couldn't login. ErrorCode = 0 ---> Procedure or function 'checkUserPassword' expects parameter '@User', which was not supplied."

And I feel like kind of an idiot about it. I'm assuming (because it seems rather obvious) that checkUserPassword is a stored procedure that gets passed the value of the 'user' parameter submitted in the Soap call, but apparently the middleware's not recognizing that I am passing the user parameter.

Edited by maxxd

Your request is missing the namespace. It's not literally the name "username" that the SOAP endpoint wants to see but an element with the local name "username" in the "http://givenNamespace.com" namespace. These would all work:

<functionCall xmlns="http://givenNamespace.com">
  <username>...</username>
</functionCall>

<foo:functionCall xmlns:foo="http://givenNamespace.com">
  <foo:username>...</foo:username>
</foo:functionCall>

Or similar versions - as long as an xmlns with the right URI is in the hierarchy.

WSDLs are also helpful on the server side for much the same reasons, so it'd be surprising if they didn't have one. It's also fairly standard for SOAP to publish them because they're so helpful.

Does http://legit.com/endpoint/givenlocation.asmx?wsdl happen to work?

2 hours ago, requinix said:

WSDLs are also helpful on the server side for much the same reasons, so it'd be surprising if they didn't have one. It's also fairly standard for SOAP to publish them because they're so helpful.

I agree - I'm a bit baffled by the lack as well. I've emailed the third-party provider again about it, so hopefully they can shed some light.

2 hours ago, requinix said:

Does http://legit.com/endpoint/givenlocation.asmx?wsdl happen to work?

No, it throws a connection exception.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.