I’m still trying to get my installation of Lucee to consume a web service over SSL.
Working with a non-standard installation of Lucee running inside Tomcat/Apache.
After trying about 30 different suggested solutions, we’re able to:
do a generic CFHTTP request over SSL without getting:
With the same code base, and an almost idenitical Apache/Tomcat/CF9 installation - this code works fine.
The XML returned from the WSDL is identical to the version that CF9 spits out.
(all this code works just fine on ACF)
One thing I did notice in the tomcat logs was an error:
lucee.runtime.exp.NativeException: java.nio.BufferOverflowException
at lucee.runtime.net.rpc.server.RPCServer.doGet(RPCServer.java:168)
at lucee.loader.servlet.CFMLServlet.service(CFMLServlet.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
Is it possible that the WSDL is too long to be handled by Lucee?
the unlimited strength JCE installed, if using the Oracle JVM
The bouncycastle JCE provider, prioritized in your java.security file
Bouncy Castle shouldn’t be required for normal HTTPS communications. It’s more likely that for some reason your JVM isn’t exposing the built-in JCE implementations.
Without some idea of how your custom install is done we aren’t going to be of much specific help.
If you’re getting “java.security.NoSuchAlgorithmException: Error constructing implementation”, you probably have a JCE problem. (JVM, not Lucee)
In Case it helps debug or as a work around for others. I used this manual soap request style to get my webservices when using lucee. I have the most control and … it works. You will want to snoop around your schema for the proper header “Value”. The one in the example is “Bing” …
So basically you gotta replace “GetUserQuotas” with your function name.
Also, replace “AuthUserName” and the others with the proper parameter names according to your function’s required attributes.
My working example looks like this:
<cfsavecontent variable="soapBody"><cfoutput>
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<GetUserQuotas xmlns="http://tempuri.org/">
<AuthUserName>Administrator</AuthUserName>
<AuthPassword>asdfsadfsdf</AuthPassword>
<DomainName>welikeit.net</DomainName>
</GetUserQuotas>
</soap:Body>
</soap:Envelope>
</cfoutput></cfsavecontent>
<cfhttp
url="http://mail.ilikeit.net/Services/svcUserAdmin.asmx" method="post" result="httpResponse">
<!---
Most SOAP action require some sort of SOAP Action header
to be used.
--->
<cfhttpparam
type="header"
name="SOAPAction"
value="http://tempuri.org/GetUserQuotas"
/>
<!---
When posting the SOAP body, I use the CFHTTPParam type of
XML. This does two things: it posts the XML as a the BODY
and sets the mime-type to be XML.
NOTE: Be sure to Trim() your XML since XML data cannot be
parsed with leading whitespace.
--->
<cfhttpparam
type="xml"
value="#trim( soapBody )#"
/>
</cfhttp>
<!---
When the HTTP response comes back, our SOAP response will be
in the FileContent atribute. SOAP always returns valid XML,
even if there was an error (assuming the error was NOT in the
communication, but rather in the data).
--->
<cfif find( "200", httpResponse.statusCode )>
<!--- Parse the XML SOAP response. --->
<cfdump var="#httpResponse.fileContent#"/>
<cfset soapResponse = xmlParse( httpResponse.fileContent ) />
</cfif>