We've got a WCF service with BasicHttpBinding and tested it via SoapUI.
My co-worker can post the requests just fine, but on my machine I get the following error returned:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<s:Fault>
<faultcode xmlns:a="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">a:InvalidSecurity</faultcode>
<faultstring xml:lang="de-AT">The caller was not authenticated by the service.</faultstring>
</s:Fault>
</s:Body>
</s:Envelope>
I'm pretty clueless as to why it doesn't work on my machine. IIS Settings are the same, too. A typical "It works on MY machine!" problem...
Related
For an application i'm developing i need to make a call on the SalesForce api. With SvcUtil i generated a proxy and integrated this in my solution. After i made a call via code, i get the following request and exception response. I use a normal basicHttpBinding.
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none"></Action>
<VsDebuggerCausalityData xmlns="http://schemas.microsoft.com/vstudio/diagnostics/servicemodelsink"></VsDebuggerCausalityData>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<login xmlns="urn:partner.soap.sforce.com">
<username>XXX</username>
<password>XXX</password>
</login>
</s:Body>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"></s:Header>
<soapenv:Body>
<soapenv:Fault>
<faultcode xmlns="">soapenv:Client</faultcode>
<faultstring xmlns="">No operation available for request {urn:partner.soap.sforce.com}login</faultstring>
</soapenv:Fault>
</soapenv:Body>
However, if call the service with SoapUI, i don't get any errors. After googling i tried to make some changes in the binding and created a custom binding for forcing the soap version to 1.2, but didn't find a good solution. What should i change in the binding configuration?
This is the SoapUI call:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:partner.soap.sforce.com">
<soapenv:Body>
<urn:login>
<urn:username>XXXX</urn:username>
<urn:password>XXXX</urn:password>
</urn:login>
</soapenv:Body>
</soapenv:Envelope>
After some research i found out that creating a proxy using "Add service reference" creates a proxy that works. So my problem is solved. Still have to check what the difference is between the generated proxies.
Before i have tested one webservice in soapUI its works fine. But now webservice was changed basicHttpBinding to wsHttpBinding over SSL. Now i'm trying to execute the webservice the following exception are im getting. Im using the webservice url in objective c. I dont how i can test and execute in SOAP UI and iphone now. any one please tel me how i can resolve.
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<a:Action s:mustUnderstand="1">http://www.w3.org/2005/08/addressing/soap/fault</a:Action>
</s:Header>
<s:Body>
<s:Fault>
<s:Code>
<s:Value>s:Sender</s:Value>
<s:Subcode>
<s:Value>a:DestinationUnreachable</s:Value>
</s:Subcode>
</s:Code>
<s:Reason>
<s:Text xml:lang="en-AU">The message with To '' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher. Check that the sender and receiver's EndpointAddresses agree.</s:Text>
</s:Reason>
</s:Fault>
</s:Body>
</s:Envelope>
You have not published your binding configuration. The default WSHttpBinding settings are note interoperable outside WCF (SPNego in the message level). Ine general basic binding is much easier to interoperate.
I am trying to access a https Java webservice from .net client but always end up with "504 Gateway Timeout" exception.
I could get the response from the same webservice using SoapUI.
I also noticed that the request soap message of SoapUI and .net client aren't similar. My question is, does the wrong format of message gives the "504 Gateway Timeout" problem ? if yest, How could i modify the soap message in .net client?
Here are the request soap message that two different app generates:
SoapUI
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v1="http://company.domain.com/EchoService/v1_00">
<soapenv:Header/>
<soapenv:Body>
<v1:Echo>test</v1:Echo>
</soapenv:Body>
</soapenv:Envelope>
.NET client
{<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope">
<s:Header>
<a:Action s:mustUnderstand="1">Echo</a:Action>
<a:MessageID>urn:uuid:7a76925d-5bf0-4f2d-a9c5-c5a026e1eefb</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Echo xmlns="http://company.domain.com/EchoService/v1_00">test</Echo>
</s:Body>
</s:Envelope>}
sorry, folks nothing to do with wcf binding or soap message but the proxy was blocking the request. SoapUI could send/receive the message because it doesn't use proxy. just changed useDefaultWebProxy="false" in binding section of configuration.
I'm trying to implement a custom WCF service client. Server uses wsHttpBinding and message security with no client credentials. I have to programically form a proper soap envelope to begin TLS handshake. I've captured initial request from standard WCF client. The message looks like this:
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</a:Action>
<a:MessageID>urn:uuid:f88d1721-29ce-4418-994e-a3796f053e63</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1">http://localhost:56635/Service1.svc</a:To>
</s:Header>
<s:Body>
<t:RequestSecurityToken xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust" Context="uuid-6549ee11-0349-4dbc-8686-6b7f0b079251-1">
<t:TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct</t:TokenType>
<t:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</t:RequestType>
<t:KeySize>256</t:KeySize>
<t:BinaryExchange ValueType="http://schemas.xmlsoap.org/ws/2005/02/trust/tlsnego" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">FgMBAFoBAABWAwFPQ8mbvU/nL8Cgu/CRIhhvVyRAYNdppNpdUY2UEi/GLQAAGAAvADUABQAKwBPAFMAJwAoAMgA4ABMABAEAABX/AQABAAAKAAYABAAXABgACwACAQA=</t:BinaryExchange>
</t:RequestSecurityToken>
</s:Body>
</s:Envelope>
The problem is, I can't figure out what value I should encode and insert into the BinaryExchange tag. Any help would be appreciated.
you do not want to go that path. there are two complex standards involved (ws-secureconversation and ssl nego). each one includes multiple message exchanges. You will need to work really hard to get all the signed and encrypted parts right. You should use the regular WCF client.
I need some help posting some XML to a WCF service. In essence, the issue I am experiencing is a HTTP response of "400: Bad request" - as descriptive as that sounds, i'm struggling to find any answers!
First of all, the service I have built in WCF is based on an existing WSDL, originally from an IBM WebSphere web service. After some manipulation (removal of MIME attachments, downloading of some remote schemas) I managed to get svcutil to generate a service interface which for all intents and purposes seems valid.
I have implemented the interface in to my WCF service and when running the WCF test client, I can attach to the service, submit a request and receive a response no problems. So far so good!
When moving to a test application for posting XML to web services via the HttpWebRequest class I start receiving "400: Bad request" responses even though I am using the XML provided by the WCF test client.
I've used WCF tracing to dump out the messages it is receiving and there is one striking difference - all of the WCF test client messages are populating correctly and displaying their header information etc, all of the once from my SOAP test utility are showing as "Malformed". Looking in to the message tab, the manual POST messages I am sending have the body wrapped in a element:
<MessageLogTraceRecord><![CDATA[<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<To s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://localhost:57567/Service1.svc</To>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://www.nowhere.co.uk/RequestService/RequestOperation</Action>
</s:Header>
</s:Envelope>
]]></MessageLogTraceRecord>
Whereas the WCF messages appear as:
<MessageLogTraceRecord>
<HttpRequest xmlns="http://schemas.microsoft.com/2004/06/ServiceModel/Management/MessageTrace">
<Method>POST</Method>
<QueryString></QueryString>
<WebHeaders>
<Connection>Keep-Alive</Connection>
<Content-Length>185</Content-Length>
<Content-Type>text/xml; charset=utf-8</Content-Type>
<Accept-Encoding>gzip, deflate</Accept-Encoding>
<Expect>100-continue</Expect>
<Host>localhost:57567</Host>
<VsDebuggerCausalityData>uIDPo4VLDcJD5AZDjB5sdmoeakEAAAAAH/hWABuWQ0iiq47QDHh0GlelCLcEx7FLibxRvpq1tTgACQAA</VsDebuggerCausalityData>
<SOAPAction>"http://www.nowhere.co.uk/RequestService/RequestOperation"</SOAPAction>
</WebHeaders>
</HttpRequest>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<To s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://localhost:57567/Service1.svc</To>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://www.nowhere.co.uk/RequestService/RequestOperation</Action>
</s:Header>
</s:Envelope>
</MessageLogTraceRecord>
I've tried tracing in Fiddler to no avail - I can't get the WCF test client to submit requests through the proxy it creates despite modifying it's app.config file. I have traced my SOAP request however can can see the following:
Content-Type: text/xml; charset="utf-8"
Accept-Encoding: gzip, deflate
Host: 127.0.0.1:57567
SOAPAction: "http://www.nowhere.co.uk/RequestService/RequestOperation"
Content-Length: 459
Expect: 100-continue
Connection: Keep-Alive
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<To s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://localhost:57567/Service1.svc</To>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://www.nowhere.co.uk/RequestService/RequestOperation</Action>
</s:Header>
</s:Envelope>
As far as I can tell, the message I am sending should be ok - outside of the headers and the message content I can't see what else could be sent.
Last thing I should say is that I am by no means a WCF expert and I have had to change the specific SOAPAction value due to commercial sensitivity..
Can anyone offer any help on this rather frustrating problem?
Thanks in advance
Thanks for the Fiddler comment - I managed to get the WCF request traced and using the xml from the request seems to work! I've since tried a full message which works against the WebSphere service against the WCF client and that works too!
I think the issue was the Action header. I believe WCF only support a couple of revisions of WSA, none of which are the one this particular WSDL was using. Looking at the original requests that were failing (pulled out of the WCF Test Client front end) the addressing namespace it was using was declared as:
xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none"
Whereas the actual WCF request that goes across to the service is declared as:
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
The actual element itself was populated with the same value, just the difference in namespace:
<wsa:Action>http://www.nowhere.co.uk/RequestService/RequestOperation</wsa:Action>
So using the correct addressing version and omitting the newer, WCF compatible version appears to have fixed the problem!