Closed Stan92 closed 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?
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 =]
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
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.....)
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!
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
I pushed this stuff to the master branch (also deleted the wss-dev branch) WSS is now available from version 1.1.0
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 >