I have deployed Mule as a web-application. I use Mule to access my webservices over HTTPS. For which I have HTTPS implemented on Mule, which works fine.
Now, I want to integrate another Web-Application instead of a webservice and want to use the same HTTPS implemented on Mule instead of implementing SSL again on my Weblogic server. But when I try the URL gets redirected to my outbound HTTP URL though my inbound endpoint is HTTPS.
Related
I have an application that sends a request to a web service. Unfortunately the application is compiled and the link to the web service is embedded in the application as http. (Yes I know how dumb that is, I didn't write it)
Recently, the 3rd party company is no longer allowing http requests, everything must be https.
The application runs as a webapp on Tomcat. The server is a windows server.
Is there a way to intercept the call to this web service and force it to use https?
As you can't change the application's source code (as it is compiled), and you can't change the web service (as it is 3rd party) either, the only way to solve this problem is making a proxy between the application and web service. To do that, you need to (assume the proxy is running in localhost):
As the web service URL is embedded into the compiled application, in order to let application send HTTP request to our proxy, hosts mapping need to change (e.g. /etc/hosts) to override DNS. For example, if the HTTP request in application is GET http://example.com/api/sample, in /etc/hosts, example.com need to be mapped to 127.0.0.1.
Make a proxy web server in localhost and open the same port as the web service. This proxy is a very simple web server (any backend programming tech can do it), it is only responsible for request-forwarding. In this way, when application send HTTP request to example.com, it sends the request to the proxy server.
After receiving HTTP request from application, the proxy server extract the request URL/header/body and send HTTPS request to example.com's real IP address. Please note: in this HTTPS request, a header host whose value is example.com should be added. 3rd party web service may check this header.
After the real response is returned from example.com, proxy will return it to the application.
Of course, you can also use reverse engineering (Java Decompiler) to get the application's "source code", change the web service URL and then compile again to a webapp. However, as the application may need to update/upgrade and it is may not under your control, this reverse engineering method is not recommended.
You could use a proxy script. Write it in any server-side language you want, for example PHP, set the API URL to this script, the script does the https request for you and pass the results back to your app.
You could also use Apache itself as the proxy and use something like: Apache config: how to proxypass http requests to https
We currently have mule ESB running on out network. Not in the DMZ.
I'm looking for information on how to configure an Apache Http server running in the DMZ to act as a proxy for a web service running on the ESB.
Thanks
The HTTP transport of Mule doesn't have any specific requirement in term of headers, so basically there's no particular recommendation for proxying HTTP requests in front of Mule.
So in the case of Apache, use mod_proxy to configure a reverse proxy in front of Mule and you should be good.
The WSO2 Server is configured to be accessed via SSL. We have deployed several services on the ESB. When we use the Carbon Admin console the services are shown. The Carbon console is access over SSL. When clicking on the WSDL 1.1 or 2.0 the link is shown as http and not https.
Could this be a configuration mistake in carbon.xml or axis2.xml?
You can access https by giving the required port (8243 , assume not set the offset).
ex:
http://my.hotname:8280/services/TestMyService?wsdl
https://my.hostname:8243/services/TestMyService?wsdl
Also you can see sample service links including http/https on endpoint section, when you click the service name and see the right top corner.
I have set up an HTTPS endpoint for my mulesoft flow which is working great in local.
https://'localhost':8081/customerquote
Once I deploy it on CloudHub I am not able to contact the url using https, the URL looks like
https://myappname.cloudhub.io/customerquote it is responding only in HTTP reporting an SSL handshake error of course.
Already tried to switch the endpoint port to 443 or 8443 without any results.
Any Idea ?
You need to use properties placeholders when you're deploying to CloudHub:
http://www.mulesoft.org/documentation/display/current/Developing+a+CloudHub+Application
If your application requires an externally accessible HTTP or HTTPS
port to receive messages, trigger events, or expose a web service or
user interface, you must declare the port using the reserved property
${http.port} or ${https.port}. On CloudHub, port ${http.port} or
${https.port} is assigned automatically by the platform services.
Traffic on port 80 to your application domain URL will be routed to
this port.
An HTTPS listener requires a TLS configuration.
Please refer this link
https://developer.mulesoft.com/docs/display/current/Building+an+HTTPS+Service
I did copy the exactly example reported here and it worked
http://www.mulesoft.org/documentation/display/current/Building+an+HTTPS+Service
We have a solution that consists of a WCF webservice on one side and a smart client on the other side.
Typically, we set up HTTPS on the webserver for the webservice so that communication between client and server happens over HTTPS.
One of our customers however has a proxy server in between that strips incoming HTTPS request from their SSL payload and forwards a plain HTTP request to the webserver:
Client > HTTPS > Proxy > HTTP > Webserver
The problem is that we are using WsHttpBinding to allow us to communicate with WCF over SSL. Typically we use that binding both on client and server and there's no issue.
But since the webservice actually receives an HTTP request, we cannot use WsHttpBinding (requires HTTPS). But we MUST use HTTPS from the client.
But of course, WCF requires the bindings between client and server to match. So we're a bit stuck and I can't find a good way to solve this issue:
We cannot set the client up to use HTTP for security reasons
We can set the service to accept HTTP requests, BUT the client won't be able to communicate with it.
Is there a certain setup that could cover this requirement?
use the wcf binding converter to get a custom binding from your wshttpbinding. then change in the custom binding from https to http element.