doedje / jquery.soap

This script uses $.ajax to send a SOAP:Envelope. It can take XML DOM, XML string or JSON as input and the response can be returned as either XML DOM, XML string or JSON too.
352 stars 148 forks source link

Add Header #9

Closed Stan92 closed 11 years ago

Stan92 commented 11 years ago

Hello, Is it possible to add a header within the envelope? Need to make a query like this;

< soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" > < soapenv:Header > < wsse:Security > < wsse:UsernameToken > < wsse:Username>xxx< /wsse:Username > < wsse:Password>xxx< /wsse:Password > </ wsse:UsernameToken > </ wsse:Security >
</ soapenv:Header > < soapenv:Body > < tem:Test > < tem:Data>{"StockID":1}< /tem:Data > < /tem:Test > < /soapenv:Body > < /soapenv:Envelope >

headwinds commented 11 years ago

great timing - I'm also looking for this... what about adding it to the SOAPtool part - see jquery.soap.js line 299

add another wrapper function adding the security header - something like:

wrapWithEnvelopeAndSecurityHeader: function(xml, isSoap12, username, password) {

            var ns = (isSoap12) ? this.SOAP12_NAMESPACE : this.SOAP11_NAMESPACE ;

            var securityHeader = '<soapenv:Header><wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">'+
                            '            <wsse:UsernameToken>'+
                            '                <wsse:Username Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">{{\"'+username+'\"}</wsse:Username>'+
                            '                <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText" '+
                            '                    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">{\"'+password+'\"}</wsse:Password>'+
                            '                <wsse:Nonce Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">{generateRandomString()}</wsse:Nonce>'+
                            '                <wsu:Created Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">{new Date().getTime()}</wsu:Created>'+
                            '            </wsse:UsernameToken>'+
                            '</wsse:Security></soapenv:Header >';

            var wrapped = "<soap:Envelope xmlns:soap=\""+ns+"\">"+securityHeader+"<soap:Body>"+xml+"</soap:Body></soap:Envelope>";                

            return wrapped;
        },

would something like that work?

doedje commented 11 years ago

Hi guys,

I was off for a nice wedding at the beach this weekend, so I react a little late...

But I think it might be relatively easy to implement wss. We need to:

1) introduce a new option to specify the parameters needed so you can do something like:

$.soap({
    wss: {
        username: $('input#username'),
        password: $('input#password')
    }
});

2) find a place to build the soap header. I think it is best done before line 168 (the wrapperfunction headwinds suggested would only work when the params are in the form of an xmlstring)

if (!!config.wss && !!config.wss.username && !!config.wss.password) {
    var wsseSecurity = new SOAPObject('wsse:Security');
    // some extra code here to create the right node structure....
    soapRequest.addHeader(wsseSecurity);
}

(maybe we should take a more general approach so you could add any Soap:Header)

I have no idea about all the ins and outs of this wss stuff... I do see a difference in both your code /soapHeaeder in terms of namespacing and number of parameters.... And I am not able to test this, so I hope you guys can fork, code and test this? Looking forward to build this stuff together =]

headwinds commented 11 years ago

At first, I had the exact same approach -- let's start with passing in username and password and then I too wondered if it would be better to pass in the entire header because some services may require different ones.

I had the same requirements as Stan92 - perhaps we're both using a standard header required for a Java wsdl.

Since soap is supposed to standardize this type of communication, I would think that the WS-Security header should be the same, however, I looked up this MSDN version and it appears to differ:

If the headers are so different, they would be problematic if not impossible to configure. Only if they all get inserted in the same place (obviously between envelope and body), would it make sense to pass in the entire header which could be created outside of jquery.soap and then you could pass in that complete xml fragment.

I did change the demo folder to demos so that we could include this java version and leave it up to future developers to help develop other versions to meet their needs.

After I committed my fork for the java version, I realized that I hadn't provided any tests. I also had to deal with some CORS issues and ended using a php proxy to trick the browser. Instead of using this proxy hack, I think it would be better to test against a mock service and which would be replaced with the actual services once it went to staging.

If we added a tests folder with mocha, sinon, and chai -- there's even a hybrid version sinon-chai - and developed a mock WSDL service - a fake server with sinon - that actually might be more valuable addition than these security headers which we may not be able to even configure.

If this library included a tests folder for those who like tests - well that would be also be good addition too - perhaps even a separate issue. This is something I'm interested in and have only just started to use them in my own professional work hence not doing them upfront but as an after thought - terrible I know ;-D

doedje commented 11 years ago

I just did some early testing with implementing the code the way I described above.... I made a branche called wss-dev and will commit my changes to there (hopefully today, or else tomorrow, I live in the Netherlands by the way, so my workingday will be over in about 15 minutes.....)

doedje commented 11 years ago

Yeah, succesfully committed my first attempt to implement this WSS stuff to the wss-dev branch.... I am interested to hear if it is working correctly..... Please let me know!

headwinds commented 11 years ago

awesome! I reviewed it and that will definitely work too - I made a new separate issue about another update I had made around logging but this one should be a really easy fix - cheers

doedje commented 11 years ago

I pushed this stuff to the master branch (also deleted the wss-dev branch) WSS is now available from version 1.1.0