I am trying to use useTLS="true" with cfldap but the error i am getting is not very helpful. It just says error connecting to ldap server.
no logs and nothing, I am using CF2021.
This is my first time using cfldap and i am not sure what needs to be done to fix this issue. if i do not use useTLS, the cfldap is connected successfully.
any clue what could be going wrong here.
You may have to specify port="636", or some other port, depending on the LDAP server configuration.
Related
We have a strange situation. It's a web service (svc1) that calls another web service (svc2) on a different box, both in websphere. Works in every previous environment.
But recently they built out another staging environment as largely a clone of a working one. The service is failing with this message everytime svc1 attempts to call svc2.
Caused by: org.apache.axis2.AxisFault: The system cannot infer the transport information from the [svc2's URL] URL.
at org.apache.axis2.description.ClientUtils.inferOutTransport(ClientUtils.java:81)
at org.apache.axis2.client.OperationClient.prepareMessageContext(OperationClient.java:304)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:180)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)
at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.execute(AxisInvocationController.java:578)
at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.doInvoke(AxisInvocationController.java:127)
at org.apache.axis2.jaxws.core.controller.impl.InvocationControllerImpl.invoke(InvocationControllerImpl.java:93)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invokeSEIMethod(JAXWSProxyHandler.java:419)
... 45 more
The URL is correct. We can point the not-working apps at a database supporting a working set of apps and it works, but when we point the working apps from that other environment at the not-working environment's DB, it stops working.
This seems to indict the DB, yet the error has nothing to do with the DB. Svc1's only DB call BEFORE the call to svc2 happens well before the service call and works fine according to logs. The logs indicate svc2 never gets the request. So how can database be the problem?
I know this isn't alot to go on, but does anyone even have suggestions on where to look to narrow this down? I can't believe the DB is the problem based on the code and when it's failing...yet the DB swapping test seems to imply it is.
I might be pointing out the obvious, but the error message is telling you one of two things: either svc1 isn't configured correctly to invoke svc2, or svc2 isn't up and running.
For clarity, if I label the working environment: enviornmentA and the not-working environment: environmentB.
Based on what you said, you were able to use environmentB.svc1 to invoke environmentA.svc2? If that is true, than environmentB.svc1 is configured correctly and working. Which leaves svc2. You said svc2 doesn't receive the request, which means its up at least. Well, like you'd mention this isn't much to go on but I'd make sure you configured svc2 correctly, since it is up. Configuring a Web Service can be complicated, but one of the things that can be configured is making a Web Service available to client invocation. So you might want to check out this link for information on how to configure it:
https://www.ibm.com/support/knowledgecenter/SSAW57_9.0.0/com.ibm.websphere.nd.multiplatform.doc/ae/twbs_publishwsdl.html.
There are a bunch of similar articles on configuring your Web Service that might help you to solve what's missing, so I would verify that the configuration for enviornmentB.svc2 matches enviornmentA.svc2 since you know that one is working.
I am using jetty version 7.5.1 .
My webservice works fine with a "http://..." endpoint, but when I change it to "https://..." things go wrong.
Endpoint e = Endpoint.create(webservice);
e.publish("https://localhost:" + serverPort + "/ws/mywebservice);
I get the following error message:
"https protocol based address is not supported".
I've tried using an SslChannelConnector, a SelectChannelConnector and the combination of both.
Connector connector = new SelectChannelConnector();
connector.setPort(59180);
SslContextFactory factory = new SslContextFactory();
factory.setKeyStore("keystore");
factory.setKeyStorePassword("password");
factory.setKeyManagerPassword("password");
factory.setTrustStore("keystore");
factory.setTrustStorePassword("password");
SslSelectChannelConnector sslConnector = new SslSelectChannelConnector(factory);
sslConnector.setPort(443);
sslConnector.setMaxIdleTime(30000);
server.setConnectors(new Connector[]{connector, sslConnector});
I also tried modifying the port in the publish path. But without success.
Could it be that something went wrong with the creation of my keystore file?
Even I put the wrong password though, it does show a different error message, explaining that my password is wrong.
My options are running out. Any ideas?
EDIT: More information:
Servlets work fine with HTTPS now. But the webservices are not. Am I maybe publishing it the wrong way ?
I found several threads on various forums with similar problems. But never found a solution. I would like to write down my solution for future victims:
The publish method only accepts the http protocol. Even if you are publishing for https, this should still be "http://...". On the other hand, you should use the port of your SSL connector.
Endpoint e = Endpoint.create(webservice);
e.publish("http://localhost:443/ws/mywebservice);
Use any other protocol and you will always get the "xxx protocol based address is not supported" exception. See source code.
Note 1: The webservice already works fine at this point. However there is a point of discussion: The generated wsdl file (at https://localhost:443/ws/mywebservice?wsdl) will reference the http://... path. You could argue if the wsdl file is a requirement or just documentation.
Correcting a hostname in a WSDL file is not that hard, but replacing the protocol is harder. The easiest solution is probably to just edit the wsdl file and host the file, which is not very "dynamic" of course.
Alternatively, I solved it by creating a WsdlServlet which replaces the address. On the other hand, it does feel bad to create an entire class just to fix 1 character. :)
Note 2: Another bug in this jetty release, is the authentication. It's impossible to offer the webservice without any authentication. The best thing you can get, after turning off all possible authentication: you will still have to use 'preemptive authentication' and enter a random username and password.
I have an application that calls a Https web service (as it seems created with java, not sure though). I get an error as response:
"Error on verifying message against security policy Error code:1000"
Now I don't exactly understand the error code and currently cannot find any responsible to answer me correctly. I don't ask for the error ofcourse cause this could be something about certificates, security from server etc.
Though I would like to catch the request client call I make, and see the whole envelope message to compare with a couple of samples I have so I might catch something.
How can I do this....I remember there is a tool that u can do such things when debugging a WCF service call, can this tool be used in this situation? Can someone rember me the name of the tool :)
I created the client using Add Service Reference, from VS 2010 and it created some custom bindings. On these bindings it created this a tag with an attribute decompressionEnabled="true" but I deleted because VS was complaining attribute is not allowed!!!
The documentation I have for these services says about authentication credential inside the message transport object that serialized in the request (requestObject) but refers to another couple of password and username properties I cannot seem to find them. Tried to add the in client.ClientCredentials.UserName.UserName and Password properties, but I get a read only error there (strange not always).
They also mention in the specifications about Connect with SOAP Security Extensions (WS-Security) which I don't understand if me, the client, has to do something from it's side, aren't these supposed to extract in the config file when generated?
Any hints and tips are welcome.
Thank you.
I'm using Recaptcha within Django. I was using the following tutorial to integrate it in my web application: http://www.marcofucci.com/tumblelog/26/jul/2009/integrating-recaptcha-with-django/
The captcha doesn't show up on my machine. Instead of the captcha the following error message is displayed:
An internal error occurred: 4A6376441D250.ADE1949.3546A435
(I get a different code each time).
To which domain did you sign the recaptcha? If you entered "127.0.0.1" in the registration make sure you use this one and not "localhost".
Today, I got this error on one of my client's website.
It was working great but suddenly it stop working. Then upon googling I find this link and renewed my API key.
But after I switched to Secure (SSL Enabled) side of my website then It stops working again.
Then, In I got this function there
recaptcha_get_html(PUBLIC_KEY, $error, true);
The third argumentation use the SSL Server, I've to enable it.
This fixed everything for me.
I am getting an error when trying to connect to an Exchange server using the cfexchangeconnection tag. First some code:
<cfexchangeconnection action="open"
server="****"
username="****"
password="****"
connection="myEX"
protocol="https"
port="443">
I know its the right server because it fails when not processing via https. I have tried:
Following all the instructions here http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec14f31-7fed.html
Prefixing username with a domain name, adding #domain name, etc and no luck.
The error I get is:
**Access to the Exchange server denied.**
Ensure that the user name and password are correct.
Any ideas
Here's an idea - this is what I needed to do to make my cfexchange connection work. Not entirely sure if it's the same problem. I think I had a 440 error, rather than your 401 error.
I'm using:
https
webdav
forms based auth
Exchange 2007
Coldfusion 8
Windows 2003 servers
Here's the connection string that worked for me. What was keeping my connection from working was the need for the formBasedAuthenticationURL. This is a poorly documented attribute by both Adobe and Microsoft.
<cfexchangeconnection action="open"
username="first.last"
password="mypassword"
mailboxname="myAcctName"
server="my.mail.server"
protocol="https"
connection="sample"
formBasedAuthentication="true"
formBasedAuthenticationURL="https://my.mail.server/owa/auth/owaauth.dll">
<cfexchangecalendar action="get" name="mycal" connection="sample">
<cfexchangefilter name="startTime" from="#theDate#" to="#theEndDate#">
</cfexchangecalendar>
<cfexchangeConnection action="close" connection="sample">
Additional notes:
IIS and WebDAV are enabled on the target Exchange server.
The username and password you're using has the appropriate permissions for
a WebDAV connection. (I'm not the Exchange admin, so I'm not sure what they
are, but I think the account needs to be allowed to connect to OWA. - Please
correct me if I am wrong.)
Optional: (don't use if you don't have to)
IF HTTPS is required, use the appropriate argument.
IF Forms Based Authentication is on in Exchange 2007 (as was my case),
you'll have to work around it using the formBasedAuthenticationURL argument.
Not sure if that's it, but I hope it is!