Ticket #292 (new defect)

Opened 4 years ago

Last modified 3 years ago

Wrong namespace on request parameter

Reported by: gthb Owned by: jortel
Priority: major Milestone: 0.3.9
Component: XML/sax Version: 0.3.8
Keywords: Cc:
Blocked By: Blocking:

Description

I am seeing a request parameter of a type defined in WSDL, passed into a request with a different XML namespace than it is defined with. To reproduce this against a live web service:

from suds.client import Client
from suds import WebFault
client = Client('http://api.rkd.reuters.com/schemas/wsdl/TokenManagement_1_HttpsAndAnonymous.wsdl')
appid = client.factory.create('{http://www.reuters.com/ns/2006/05/01/webservices/rkd/Common_1}ApplicationID')
appid.set('foo')
try:
    client.service.CreateServiceToken_1(ApplicationID=appid)
except WebFault, e:
    print e.fault.Reason

This prints out:

(Reason){
   Text = "http://api.rkd.reuters.com:80/api/2006/05/01/TokenManagement_1.svc/Anonymous: cvc-particle 3.1: in element {http://www.reuters.com/ns/2006/05/01/webservices/rkd/TokenManagement_1}CreateServiceToken_Request_1 of type {http://www.reuters.com/ns/2006/05/01/webservices/rkd/TokenManagement_1}CreateServiceToken_Request_1, found <ns0:ApplicationID> (in namespace http://www.reuters.com/ns/2006/05/01/webservices/rkd/TokenManagement_1), but next item should be {http://www.reuters.com/ns/2006/05/01/webservices/rkd/Common_1}ApplicationID"
 }

where the ApplicationID has a namespace different from the one it is defined with. print client also shows ApplicationID as belonging to the Common_1 namespace. So it seems like serializing it in the TokenManagement_1 namespace is a suds bug — correct? Or am I doing something wrong in the above?

Encountered first in 0.3.8 and then also on trunk.

Attachments

ticket-292-proposed-fix.patch (454 bytes) - added by gthb 4 years ago.
Proposed patch
suds-292_wsdlns-working.diff (450 bytes) - added by htj 3 years ago.
Modified version of the previous patch. Works for me.

Change History

Changed 4 years ago by gthb

Proposed patch

comment:1 Changed 4 years ago by gthb

The tiny patch I just attached fixes this problem for our use case; can't say whether it's complete or whether it might cause any regressions, but at least the tests in builtin.py all passed (one test failed in public.py but that was due to some malformed .asmx URL, presumably unrelated).

comment:2 Changed 3 years ago by htj

Hi, I had similar problems with 0.4. The patch attached here did fix the problematic element in question, but the change cascaded wrongly as the following elements (which did not have any namespace) got the namespace of the parent.

I've attached a patch which fixes it for me. Like gthb, I have no idea if this patch is correct.

Changed 3 years ago by htj

Modified version of the previous patch. Works for me.

Note: See TracTickets for help on using tickets.