Can you help me solve this SUDS/SOAP issue?

Question

So I'm trying to access this api https://www.clarityaccounting.com/api-docs/ using SUDS. Here is the code that should work:

from suds.client import Client
client = Client('https://www.clarityaccounting.com/api/v1?wsdl')
token = client.service.doLogin('demo', 'demo', 'www.kashoo.com', 'en_US', 300000)

But I get this error:

WebFault: Server raised fault: 'No such operation:  (HTTP GET PATH_INFO: /api/v1)'

Their support guy says that the request should look like this:

<SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:api="http://api.service.books/">
  <SOAP-ENV:Body>
     <api:doLogin>
        <username>demo</username>
        <password>demo</password>
        <siteName>www.kashoo.com</siteName>
        <locale>en_US</locale>
        <duration>300000</duration>
     </api:doLogin>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

But SUDS' looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope 
xmlns:ns0="http://api.service.books/" 
xmlns:ns1="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Header/>
   <ns1:Body>
      <ns0:doLogin>
         <username>demo</username>
         <password>demo</password>
         <siteName>www.kashoo.com</siteName>
         <locale>en_US</locale>
         <duration>300000</duration>
      </ns0:doLogin>
   </ns1:Body>
</SOAP-ENV:Envelope>

I'm a real SOAP and SUDS newbie but I heard that SUDS is the best SOAP library to use from here: What SOAP client libraries exist for Python, and where is the documentation for them?

So my question is simply what are the crucial parts that are different and that are making the request fail and how can I configure SUDS to send the properly formatted request?

Lussier

Answer 1

At first glance looks like the problem you're having is with SSL. You are accessing an https URL, and the Transport handler for suds.client talks http by default.

The problem
If you look at the bottom of the WSDL it is specifying the default location as http://www.clarityaccounting.com/api/v1, which is an http URL, but the WSDL is SSL.

 <wsdl:service name="v1">
    <wsdl:port binding="tns:v1SoapBinding" name="BooksApiV1Port">
      <soap:address location="http://www.clarityaccounting.com/api/v1"/>
    </wsdl:port>
 </wsdl:service>

If you do an http GET on that URL, you get the error message you received:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
        <soap:Fault>
            <faultcode>soap:Server</faultcode>
            <faultstring>No such operation:  (HTTP GET PATH_INFO: /api/v1)</faultstring>
        </soap:Fault>
    </soap:Body>
</soap:Envelope>

The Solution
To fix this you need to override the default location when you call the Client constructor to make it stick with https:

>>> url
'https://www.clarityaccounting.com/api/v1?wsdl'
>>> client = Client(url, location='https://www.clarityaccounting.com/api/v1')
>>> token = client.service.doLogin('demo', 'demo', 'www.kashoo.com', 'en_US', 300000)
>>> token
(authToken){
   authenticationCode = "ObaicdMJZY6UM8xZ2wzGjicT0jQ="
   expiryDate = 2010-03-05 12:31:41.000698
   locale = "en_US"
   myUserId = 4163
   site = "www.kashoo.com"
 }

Victory!

Pro tip for future debugging purposes: Turn on full logging debugging. SUDS uses the standard logging library, so it gives you a lot of control. So I cranked it all up to DEBUG:

import logging
logging.basicConfig(level=logging.INFO)
logging.getLogger('suds.client').setLevel(logging.DEBUG)
logging.getLogger('suds.transport').setLevel(logging.DEBUG)
logging.getLogger('suds.xsd.schema').setLevel(logging.DEBUG)
logging.getLogger('suds.wsdl').setLevel(logging.DEBUG)

This is what helped me narrow it down, because it was clearly saying it was sending over http:

DEBUG:suds.transport.http:sending:
URL:http://www.clarityaccounting.com/api/v1
(xml output omitted)

And then the response said so as well:

DEBUG:suds.client:http failed:

Blouin

Glad to help out! It was a fun problem to figure out on a Friday afternoon. – Blouin

Thank you! I was just experiencing the same problem with a different web service, but the same https / http issue. I couldn't find how to set the client to use https even though the WSDL said to use http. – Sever

It's a common problem when people host web services over HTTPS but forget to update the WSDL accordingly OR don't configure their servers to redirect HTTP to HTTPS properly. I'm glad I was able to help! – Blouin

Thanks suds for fixing more of Microsoft's crap! – Pottage

Answer 2

Using suds-jurko https://pypi.python.org/pypi/suds-jurko which is a maintained fork of suds. You can pass in an __inject option where you can give it the raw xml you want to send.

from suds.client import Client

username, password, sitename, locale, duration = 'demo', 'demo', 'www.kashoo.com', 'en_US', 300000

raw_xml = """<SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:api="http://api.service.books/">
  <SOAP-ENV:Body>
     <api:doLogin>
        <username>{0}</username>
        <password>{1}</password>
        <siteName>{2}</siteName>
        <locale>{3}</locale>
        <duration>{4}</duration>
     </api:doLogin>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>""".format(username, password, sitename, locale, duration)

client = Client(url, location)
result = client.service.doLogin(__inject={'msg':raw_xml})

I feel like I should document all the ways that one can inspect the Raw soap that suds generates here.

1. Using a nosend flag when constructing the client. Please note that with the flag set to True, suds will just generate the soap but not send it.

   client =Client(url, nosend=True)
res = client.service.example()
print res.envelope #prints the raw soap

2. Using logging. Here we are only logging suds.transport.http, so it will only output whatever is sent/received.

   import logging
import sys
handler = logging.StreamHandler(sys.stderr)
logger = logging.getLogger('suds.transport.http')
logger.setLevel(logging.DEBUG), handler.setLevel(logging.DEBUG)
logger.addHandler(handler)

3. Using the MessagePlugin

   from suds.plugin import MessagePlugin
class MyPlugin(MessagePlugin):
def marshalled(self, context):
#import pdb; pdb.set_trace()
print context.envelope.str()

   client = Client(url, plugins=[MyPlugin()])

Not only does the MessagePlugin give you the ability to inspect the soap generated but you can also modify it before sending, see-> https://jortel.fedorapeople.org/suds/doc/suds.plugin.MessagePlugin-class.html

Enyedy

Answer 3

It shouldn't be a problem related to connecting to a service over HTTPS. I'm using suds to do the same thing. I've tried a few approaches to your WSDL file (not an expert myself) and encountered the same error. What you should do as practice with suds though is use the factory method, e.g.

login = client.factory.create('doLogin')
login.username = 'username'
etc...

Where anything sent to the create function is one of the types defined in the WSDL file. If you create that type in the shell you can run 'print login' to see its additional properties.

Hope this at least tells you where the problem isn't (with HTTPS). Also, I noticed that the soapAction headers aren't set in the WSDL file, not sure how suds or the service handles requests without that.

Shem

As you can see in my revised answer, the problem wasn't with connecting over https, but with an inconsistency in the WSDL being served over https, meanwhile pointing the SOAP calls to http. My guess is that the way they have the service configured to redirect incoming URLs from http to https is the source of the problem. All we've really done is worked around it. – Blouin