I am trying to connect MuleSfot to Salesforce SOAP based web service using Web Service Consumer. Trying in SOAPUI first but getting INVALID_SESSION_ID, I need to login in Salesforce to get the ID but not clear.
Help please!!
EDIT 1
Request I am sending
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:="http://soap.sforce.com/schemas/class/WebService">
<soapenv:Header>
<AllowFieldTruncationHeader>
<allowFieldTruncation>false</allowFieldTruncation>
</AllowFieldTruncationHeader>
<DebuggingHeader>
<!--Zero or more repetitions:-->
<categories>
<category>All</category>
<level>None</level>
</categories>
<debugLevel>None</debugLevel>
</DebuggingHeader>
<CallOptions>
<client>?</client>
</CallOptions>
<SessionHeader>
<sessionId>?</sessionId>
</SessionHeader>
</soapenv:Header>
<soapenv:Body>
</soapenv:Body>
</soapenv:Envelope>
? for client is fine.
It's session ID which I cant get
RAW REQUEST
POST https://cs61.salesforce.com/services/Soap/class/WebService HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: ""
Content-Length: 972
Host: cs61.salesforce.com
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
RAW RESPONSE
HTTP/1.1 500 Server Error
Date: Tue, 24 Jan 2017 04:18:15 GMT
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Security-Policy: reflected-xss block;report-uri /_/ContentDomainCSPNoAuth?type=xss
Content-Security-Policy: referrer origin-when-cross-origin
Set-Cookie: BrowserId=CdHsqmLzR3OFRklUfp1p3g;Path=/;Domain=.salesforce.com;Expires=Sat, 25-Mar-2017 04:18:15 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/xml; charset=utf-8
Transfer-Encoding: chunked
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sf="http://soap.sforce.com/schemas/class/WebService">
<soapenv:Body>
<soapenv:Fault>
<faultcode>sf:INVALID_SESSION_ID</faultcode>
<faultstring>INVALID_SESSION_ID: Invalid Session ID found in SessionHeader: Illegal Session</faultstring>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
I got it. Needed to login to Salesforce first, used the login() call and get session ID.
Thanks
Related
The following request was blocked by AWS web app firewall cross site scripting rule. But what is suspicious? All seem normal to me!
POST /package.asmx HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 4.0.30319.42000)
VsDebuggerCausalityData: uIDPo313Tw/LhjNJn3K1llXBHoEAAAAA9KbUetLg5kixdCJ3yXly/+zfyrFP4XJPrTb7S6ewbdQACQAA
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://www.ingeneus.com.au/GetAccountStatus"
Host: www.eyecloud.net.au
Content-Length: 618
Expect: 100-continue
Connection: Keep-Alive
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<GetAccountStatus xmlns="http://www.ingeneus.com.au/">
<sBusinessDomainId>1</sBusinessDomainId>
<strRddSerialNum>EC1600027</strRddSerialNum>
<strPassword>2bb4f34fdff49f1f56b6e708ab49ff22</strPassword>
<bRegisteredInCloud>false</bRegisteredInCloud>
<bAssignedToClinic>false</bAssignedToClinic>
<bAccountActive xsi:nil="true" />
<cPaymentStatus xsi:nil="true" />
</GetAccountStatus>
</soap:Body>
</soap:Envelope>
The header SOAPAction: "http://www.ingeneus.com.au/GetAccountStatus" is triggering the rule.
Change your code so that this header is removed or changed to SOAPAction: "".
I am sending a request from SoapUI and I am getting an error in return.
I have no idea how to resolve this.
Request:
POST http://localhost:8080/services/ApiService/ HTTP/1.1
Accept-Encoding: gzip,deflate
SOAPAction: ""
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Length: 345
Host: localhost:8080
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
Response:
HTTP/1.1 500 Server Error
Set-Cookie: EZSESSIONID=y4k1kp87msmg5ni4migdd65f;Path=/
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_89EA7A7AB1A241D9571457445576391; type="application/xop+xml"; start="<0.urn:uuid:89EA7A7AB1A241D9571457445576392#apache.org>"; start-info="text/xml"
Transfer-Encoding: chunked
Server: Jetty(7.6.3.v20120416)
--MIMEBoundaryurn_uuid_89EA7A7AB1A241D9571457445576391
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:89EA7A7AB1A241D9571457445576392#apache.org>
<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><soapenv:Fault><faultcode>soapenv:Server</faultcode><faultstring>org.apache.axiom.om.impl.llom.OMTextImpl cannot be cast to org.apache.axiom.om.OMElement</faultstring><detail /></soapenv:Fault></soapenv:Body></soapenv:Envelope>
--MIMEBoundaryurn_uuid_89EA7A7AB1A241D9571457445576391--
ServerLog:
ERROR 2016-03-08 19:29:36.133 AxisEngine [request-19]
org.apache.axiom.om.impl.llom.OMTextImpl cannot be cast to
org.apache.axiom.om.OMElement org.apache.axis2.AxisFault:
org.apache.axiom.om.impl.llom.OMTextImpl cannot be cast to
org.apache.axiom.om.OMElement at
org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
~[axis2-kernel-1.4.1.jar:na]
I have simple web service running on http://calculator.gear.host/Service1.svc
I have no problem while do call from WCF Test Client and have error while calling from gSOAP c++ client.
HTTP/1.1 415 Cannot process the message because the content type 'application/soap+xml; charset=utf-8; action="http://tempuri.org/IService1/GetData"' was not the expected type 'text/xml; charset=utf-8'.
Packets on Fiddler:
WCF Test Client
Request
POST http://calculator.gear.host/Service1.svc HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/ICalculator/GetData"
Host: calculator.gear.host
Content-Length: 158
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><GetData xmlns="http://tempuri.org/"><value>77</value></GetData></s:Body></s:Envelope>
gSOAP
Request
POST http://calculator.gear.host/Service1.svc HTTP/1.1
Host: calculator.gear.host
User-Agent: gSOAP/2.8
Content-Type: application/soap+xml; charset=utf-8; action="http://tempuri.org/IService1/GetData"
Content-Length: 536
Connection: close
SOAPAction: "http://tempuri.org/IService1/GetData"
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns4="http://schemas.datacontract.org/2004/07/WcfService2" xmlns:ns3="http://schemas.microsoft.com/2003/10/Serialization/" xmlns:ns1="http://tempuri.org/"><SOAP-ENV:Body><ns1:GetData><ns1:value>55</ns1:value></ns1:GetData></SOAP-ENV:Body></SOAP-ENV:Envelope>
Answer
HTTP/1.1 415 Cannot process the message because the content type 'application/soap+xml; charset=utf-8; action="http://tempuri.org/IService1/GetData"' was not the expected type 'text/xml; charset=utf-8'.
Cache-Control: private
Content-Length: 0
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Set-Cookie: ARRAffinity=7ac8ab2e2023ddbeb7d4f86322b3ed25bc003394df0030ed244a6fc5c10ec47c;Path=/;Domain=calculator.gear.host
Set-Cookie: WAWebSiteSID=9095f7410a074a959c2084564368b742; Path=/; HttpOnly
Date: Tue, 28 Jul 2015 15:03:28 GMT
Connection: close
I' have the same problem with a service not generated with gSOAP (probably using some tool in C#).
For your client gSOAP, recompile your WSDL file (soapcpp2.exe) using option -1 (generate SOAP 1.1 bindings).
This works for me.
I know about the SOAP -based webservices that SOAP messages, which are XML in turn, are transferred on the network, from client to the server. But what kind of data is transferred in case of RESTful webservice ?
from Wikipedia https://en.wikipedia.org/wiki/Representational_state_transfer
RESTful systems typically, but not always, communicate over the
Hypertext Transfer Protocol with the same HTTP verbs (GET, POST, PUT,
DELETE, etc.)
You can try yourself easily with curl or Fiddler. For example GitHub API is nice to experiment with.
Send this with Fiddler:
GET https://api.github.com/users/octocat HTTP/1.1
Host: api.github.com
User-Agent: Fiddler
and you will get this response:
HTTP/1.1 200 OK
Server: GitHub.com
Date: Fri, 10 Jul 2015 10:23:10 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 1155
Status: 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 58
X-RateLimit-Reset: 1436527371
Cache-Control: public, max-age=60, s-maxage=60
Last-Modified: Mon, 06 Jul 2015 23:59:25 GMT
ETag: "d811d5844be3eaf9ab1f60dd36198aa9"
Vary: Accept
X-GitHub-Media-Type: github.v3; format=json
X-XSS-Protection: 1; mode=block
X-Frame-Options: deny
Content-Security-Policy: default-src 'none'
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: ETag, Link, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval
Access-Control-Allow-Origin: *
X-GitHub-Request-Id: 3EAD7342:6BF1:E180441:559F9D0D
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
X-Content-Type-Options: nosniff
Vary: Accept-Encoding
X-Served-By: bd82876e9bf04990f289ba22f246ee9b
{"login":"octocat","id":583231,"avatar_url":"https://avatars.githubusercontent.com/u/583231?v=3","gravatar_id":"","url":"https://api.github.com/users/octocat","html_url":"https://github.com/octocat","followers_url":"https://api.github.com/users/octocat/followers","following_url":"https://api.github.com/users/octocat/following{/other_user}","gists_url":"https://api.github.com/users/octocat/gists{/gist_id}","starred_url":"https://api.github.com/users/octocat/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/octocat/subscriptions","organizations_url":"https://api.github.com/users/octocat/orgs","repos_url":"https://api.github.com/users/octocat/repos","events_url":"https://api.github.com/users/octocat/events{/privacy}","received_events_url":"https://api.github.com/users/octocat/received_events","type":"User","site_admin":false,"name":"The Octocat","company":"GitHub","blog":"http://www.github.com/blog","location":"San Francisco","email":"octocat#github.com","hireable":false,"bio":null,"public_repos":5,"public_gists":8,"followers":1054,"following":6,"created_at":"2011-01-25T18:44:36Z","updated_at":"2015-07-06T23:59:25Z"}
The following link answered my query. Now I know that the data sent in case of RESTful services is 'raw http' data.
http://rest.elkstein.org/2008/02/how-simple-is-rest.html
I have a web service that requires basic authorisation and a user behind an internet proxy that requires NTLM authorisation. I also have a forms application that makes calls to the web service and also asks the user for the web service credentials (which are different from the NTLM credentials).
I got the app configuration working (WCF ServiceModel), it's using the default proxy credentials, the request is authenticating with the proxy, but after it authenticates with the web service it does not send the request body for some reason.
The process works if I test locally without the NTLM proxy. Sorry about the long examples, but I had to include them.
1st request:
Send:
POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue
Accept-Encoding: gzip, deflate
Proxy-Connection: Keep-Alive
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>
Receive:
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: NTLM
Proxy-Authenticate: BASIC realm="corporaterealm"
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Proxy-Connection: close
Set-Cookie: BCSI-CS-36204A5A7BBD24D9=2; Path=/
Connection: close
Content-Length: 1057
Proxy-Support: Session-Based-Authentication
[...]
2nd request:
Send:
POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate
Proxy-Authorization: NTLM TlRMTVNTUAABAAAAB7IIoggACAAxAAAACQAJACgAAAAFASgKAAAAD1dTUkswNDg3MENPTUVUTkVU
Host: www.myservice.com
Content-Length: 0
Receive:
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: NTLM TlRMTVNTUAACAAAAEAAQADgAAAAFgomiysOwieqrhFEAAAAAAAAAALIAsgBIAAAABQLODgAAAA9DAE8ATQBFAFQATgBFAFQAAgAQAEMATwBNAEUAVABOAEUAVAABABoAVgBJAC0AUgBJAEMASwBEAEMALQAwADAAMQAEABwAYwBvAG0AZQB0AG4AZQB0AC4AbABvAGMAYQBsAAMAOABWAEkALQBSAEkAQwBLAEQAQwAtADAAMAAxAC4AYwBvAG0AZQB0AG4AZQB0AC4AbABvAGMAYQBsAAUAHABjAG8AbQBlAHQAbgBlAHQALgBsAG8AYwBhAGwAAAAAAA==
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Proxy-Connection: Keep-Alive
Set-Cookie: BCSI-CS-36204A5A7BBD24D9=2; Path=/
Connection: Keep-Alive
Content-Length: 1074
Proxy-Support: Session-Based-Authentication
[...]
3rd request:
Send:
POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate,gzip, deflate
Proxy-Authorization: NTLM TlRMTVNTUAADAAAAGAAYAHgAAAAYABgAkAAAABAAEABIAAAADgAOAFgAAAASABIAZgAAAAAAAACoAAAABYKIogUBKAoAAAAPQwBPAE0ARQBUAE4ARQBUAFAAYQByAHMAbwBuAEoAVwBTAFIASwAwADQAOAA3ADAAlap7g+mPRMEAAAAAAAAAAAAAAAAAAAAARLAhi5lf3nd+l9xENAcu2W6xf6iJbyM6
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>
Receive:
HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Basic realm="myrealm"
X-Powered-By: ASP.NET
Date: Tue, 31 May 2011 13:09:33 GMT
Cache-Control: proxy-revalidate
Content-Length: 1656
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Proxy-support: Session-based-authentication
Age: 0
[...]
4th request:
Send:
POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate,gzip, deflate,gzip, deflate
Authorization: Basic Y29nZW50YVxjb21ldC1kbTM6Kmh0JTg2NCU=
Proxy-Authorization: NTLM TlRMTVNTUAABAAAAB7IIoggACAAxAAAACQAJACgAAAAFASgKAAAAD1dTUkswNDg3MENPTUVUTkVU
Host: www.myservice.com
Content-Length: 0
Receive:
HTTP/1.1 400 Bad Request
Date: Tue, 31 May 2011 13:09:33 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
Cache-Control: private, proxy-revalidate
Content-Length: 0
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Age: 0
I don't understand why it doesn't send the envelope in the 4th request. The two handshakes are done, so theoretically everything should be fine.
When I do this locally without the NTLM proxy, the envelope gets sent as expected:
1st request:
Send:
POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>
Receive:
HTTP/1.1 401 Unauthorized
Content-Length: 1656
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Basic realm="myrealm"
X-Powered-By: ASP.NET
Date: Tue, 31 May 2011 13:31:46 GMT
[...]
2nd request:
Send:
POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate
Authorization: Basic Y29nZW50YVxjb21ldC1kbTM6Kmh0JTg2NCU=
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>
Receive:
HTTP/1.1 200 OK
Date: Tue, 31 May 2011 13:31:47 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
Set-Cookie: ASP.NET_SessionId=svv4i11awg05v1j5viz1impo; path=/; HttpOnly
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 5127
[...]
I had to change the server security configuration to accept Digest authentication. For some reason that works while Basic doesn't.
I encountered a potentially similar issue and believe in my case this may be related to the establishment of the original NTLM connection to the proxy.
In my experience I had three requests going out in sequence each hour, with a retry configured.
Of these requests two would work, one would fail with a 400, and then when the first retried it worked as well.
There is a similiar issue with IE identified here: http://blogs.msdn.com/b/asiatech/archive/2012/01/30/400-bad-request-when-posting-webservice-or-wcf-request-from-ie.aspx
I ran some network traces and watched the behaviour and noticed that often the TCP Streams seemed to get shared, so that one of the requests would end up sending an NTLM authentication message (the zero content length) to the proxy after the other had already authenticated. In this situation the proxy just passed through the zero content message (as the stream had already authenticated).
What fixed it for me was moving to a WCF-Custom customBinding (using textMessageEncoding with a messageVersion of Soap11 to maintain my basicHttpBinding behaviour) and (not sure if required) setting keepAliveEnabled to false.
Unfortunately I doubt this is much help for your particular situation, but more info never hurts.