I am using WSClient to connect to a wsdl server.
def proxy = new MyWSClient("https://", this.class.classLoader)
proxy.initialize()
All works as expected with http request.
But when I use SSL(https) I get an error "The document has moved", in the browser it appears.
I do see that the plugin connected to the server since i get the prints of the plugin of the available methods:
INFO MyWSClient - available method: {http://...}checkCredentials
Questions:
in the print of available methods, as can be seen, the service is http and not https - why?
Does WSClient support SSL calls?
Is there a better way to implement a call to a wsdl in grails?
Thanks in advance
Related
I want to deploy an webapp for internal use only. This webapp is firing POST requests to other internal services. The problem is that the services are not running with TLS. The deployed webapp on Cloud Run has HTTPS activated by default. Therefore I can not launch any HTTP POST request to the services.
Any idea how I can deploy the app without TLS/HTTPS active?
Code snippet:
console.log('Starting Import: ' + this.urlString)
const xmlHttp = new XMLHttpRequest()
xmlHttp.open('POST', this.urlString, true)
xmlHttp.send(null)
console.log(xmlHttp.responseText)
Log:
Starting Import: https://34.95.76.221/importer/start/CATALOG001?file=test.xml
Chrome console error:
Importer-Controls.vue:103 POST https://34.95.76.221/importer/start/CATALOG001?file=test.xml net::ERR_CONNECTION_CLOSED
You are trying to make an insecure request from a secure context. You either need to enable SSL for your "internal services" or you need to build a service that proxies the request from HTTPS->HTTP.
For example, you could make a simple Cloud Run app that wraps the HTTP request and performs it on the backend instead of on the frontend. Then your frontend could make an HTTPS request to the proxy.
Whenever I try to add the following endpoint, "http://ws.cdyne.com/phoneverify/phoneverify.asmx", during the Managed API setup process and press the Test button I get an error on the server. ERROR - APIProviderHostObject Error occurred while connecting to backend : "stackOverflow preventing me from showing this link", reason: Connect to ws.cdyne.com:80 timed out
When I try this exact same process on a machine outside of our proxy it works fine. I have gone into the axis2.xml file and added proxy information and even went as far as installing cntlm and setting the proxy to localhost - same error.
I can browse to the above link just fine on this machine.
My environment is Windows 10.
I assume you talk about clicking the Test button when providing Backend Endpoint in API publisher.
The way that Test button works at the moment (as far as I understand) is that it invokes HTTP HEAD method on the endpoint provided (because according to RFC 2616, "This method is often used for testing hypertext links for validity, accessibility, and recent modification.")
Then it checks response. If response is valid or 405 (method not allowed), then the URL is marked as Valid.
Thus sometimes, if backend is not properly following RFC, you might get otherwise working URLs declared as Invalid during the test because of that improper HEAD response evaluation. Obviously, this is just a check for your convenience and you can ignore the check if you know the endpoint works for the methods and resources you need it to work.
So my advice would be to try ignoring the Test and just finishing setting up and publishing the API.
P.S. I am checking it on WSO2 API Cloud but behavior is identical to downloadable API Manager.
I just setup the example from https://github.com/simplabs/ember-cli-simple-auth-example using Cloud9 and I get a 400 Bad Request error when I try to login.
I'm pretty sure this is due to fact that Cloud9 only opens port 80 (as referenced in this note from http://log.simplabs.com/post/90339547725/using-ember-simple-auth-with-ember-cli:
As the OAuth 2.0 authenticator would by default use the same domain
and port to send the authentication requests to that the Ember.js is
loaded from you need to configure it to use http://localhost:3000
instead.
Unfortunately I don't know how I might work around this. Any ideas?
Add the host to the whitelist in the config:
window.ENV['simple-auth'] = {
crossOriginWhitelist: ['http://some.other.domain:1234']
}
More info in the Cross Origin Authorization section of the docs
2 simple questions :
Do all http requests make thru http adapter do go thru the worklight server first?
If so then does it mean even a http adapter request to a public web site say a request to yahoo site for a stock price would also go thru worklight server first then next to the yahoo web site? If so then how do I make a http request without going thru the worklight server? I just want to go straight to yahoo web site without the "intermediate" server (i.e. workligth server)
1) Do all http requests make thru http adapter do go thru the
worklight server first?
Yes. Worklight Adapters work by executing JavaScript on the Worklight Server using Mozilla Rhino. You can read more about Adapters in the IBM Worklight Getting Started Modules. Look at Modules 5 and 6 for Adapter specific details. There are also code samples you can try next. The API documentation is in IBM InfoCenter. There is also a Developer Works article that talks about adapters that you may find helpful.
2) If so then does it mean even a http adapter request to a public web
site say a request to yahoo site for a stock price would also go thru
worklight server first then next to the yahoo web site?
Yes.
I just want to go straight to yahoo web site without the
"intermediate" server (i.e. workligth server)
IBM Worklight ships with jQuery, you can use the ajax method. Here's an example:
WLJQ.ajax( "http://finance.yahoo.com/d/quotes.csv?s=DOW+MSFT+AAPL+GOOG&f=snl1" )
.done(function (data) {
console.log(data);
});
Note that WLJQ is the namespace for the version of jQuery that Worklight ships. You can use jQuery or $ by doing: var $ = WLJQ; or var jQuery = WLJQ;.
You should get something like this back:
"DOW","Dow Chemical Comp",30.89
"MSFT","Microsoft Corpora",27.37
"AAPL","Apple Inc.",448.97
"GOOG","Google Inc.",790.13
If you use the adapter API on the client side then your request with go through the Worklight server. You can still make AJAX requests from the client side and skip the server. Essentially you'd be making server requests in the same way you would in Cordova, which means using a whitelist to allow your requests to access third party servers.
Of course You can access it directly without calling any adapter functions using simple jquery ajax calls.
$.ajax({
url: url,
data: data,
success: success,
dataType: dataType
});
or
$.get(url, function() {
alert( "success" );
})
.done(function() {
alert( "second success" );
})
.fail(function() {
alert( "error" );
})
.always(function() {
alert( "finished" );
});
Do all http requests make thru http adapter do go thru the worklight
server first?
Absolutely not, it is entirely up to you. If you are using HTTP Adapters, then the HTTP request would be initiated from the Worklight Server and it would serve you back the response.
If so then does it mean even a http adapter request to a public web
site say a request to yahoo site for a stock price would also go thru
worklight server first then next to the yahoo web site? If so then how
do I make a http request without going thru the worklight server? I
just want to go straight to yahoo web site without the "intermediate"
server (i.e. workligth server)
If you are using a HTTP Adapter, then it would go through Worklight Server as per the first answer.
If you do not want the intermediate server, then you can use the conventional means of doing the HTTP request as you would do otherwise either through the Javascript /Ajax layer or natively (Android/iOS/Windows..)
Adapters are useful when it comes to security which Worklight uses to make sure that the request is initiated from the registered device - the authentication is done by exchanging device tokens etc.
I think you are missing an important point about the adapter architecture in WL. The adapter lives in the server, so by definition, any request you make with it will "go thru" the server. However, the information is not going through your WAS (or Tomcat) server.
Is there a reason you don't want to use the adapter? I would recommend using it since it makes it easier to pull down data, whether from a RESTful http call or database query.
If you did want to get around the adapter, there are issues with cross-domain authorization. I don't have much experience in this area, but you may be able to get around it using something like jQuery.ajax().
I'm getting repeated Microsoft.Http.HttpStageProcessingException timeout exceptions while trying to use the REST Starter kit's HttpClient. This has been working fine when used locally, but is failing when going remote.
The client is a c# process that runs as a windows service and uses HttpClient for making REST calls to our Java app server running in Tomcat6. When I started troubleshooting this, I came across a similar post on MSDN's forums: http://social.msdn.microsoft.com/Forums/en/wcf/thread/88487549-ce45-49d3-95e4-7ed413cbcfbc
Unfortunately, I can't isolate it to simply a Content-Length problem.
If anyone has any suggestions on how to solve this problem, I would greatly appreciate it - even if it means using HttpWebRequest directly. I understand HttpClient uses HttpWebRequest under the hood, but perhaps it's making some assumptions.
Found the solution. It turns out that the default number of outbound http connections when using the HttpClient seems to be 2. After I used the ServicePointManager static singleton to set the DefaultConnectionLimit for my client AppDomain to 10, everything worked fine.
Now, this is a little concerning, however - because I'm used to writing multi-threaded apps and using the new .NET 4 Tasks - so I really don't like having hard limits on outbound connections. Can anyone provide any links that provide details on how the low-level .NET Http handling works and what knobs control what settings?
Thanks again for the help,
Bob
NEVERMIND - found it myself, should have googled first - this MSDN blog on the Http Client protocol provides a good description of what's going on under-the-hood:
httpclient protocol blog
If it works locally or remotely via Fiddler then it is a problem with HTTP proxy. Your current configuration is not using proxy but Fiddler by default uses proxy configured for IE.
Get the same problem and solution is to Dispose method on response (maybe method named Close may be more clear) else response still occupy the socket and you have to increase the DefaultConnectionLimit to open new socket for each new request untill max limit reach (dirty and slow).
So the solution was:
HttpResponseMessage resp = this.HttpClient.Delete(uri);//or verb get/post/put
try {
//.... do what you need with response
}
finally {
resp.Dispose(); //free the socket for a new request
}