I've been trying to use Apache Camel's Http4 component to connect to a HTTPS URL that needs Basic authentication. The connection needs to be done through an authenticated HTTP proxy.
So, according to the docs, I configure the Camel endpoint like this:
.toD("https4://target.host/resource?
bridgeEndpoint=true
&mapHttpMessageBody=false
&proxyAuthHost=my.proxy.host
&proxyAuthPort=myProxyPort
&proxyAuthUsername=proxyUser
&proxyAuthPassword=proxyPassword
&proxyAuthScheme=http4
&authenticationPreemptive=true
&authUsername=myUser
&authPassword=myPassword")
Which results in a 403 - Forbidden response from the target server. Looking through the org.apache.http.wire logs, it shows that the proxy credentials proxyUser / proxyPassword are forwarded to the target server instead of the intended myUser/myPassword in the Authorization header.
Debugging the source for CompositeHTTPConfigurer.configureHttpClient, ProxyHttpClientConfigurer.configureHttpClient and BasicAuthenticationHttpClientConfigurer.configureHttpClient, it seems that because both configurers are setting their credentials to the HttpClientBuilder by means of setDefaultCredentialsProvider, one of them is lost - gets overwritten - in the process.
Looks like it could be a bug in Camel's Http4 component? Or am I missing something?
This is Camel 2.18.2 with Spring Boot 1.5.1.RELEASE.
After raising this question on the Apache Camel Users list, it seems the bug is confirmed.
I solved it using camel-http instead of camel-http4. Endpoint parameters needed a slight tweaking:
.toD("https://target.host/resource?
bridgeEndpoint=true
&proxyHost=my.proxy.host
&proxyPort=myProxyPort
&proxyAuthUsername=proxyUser
&proxyAuthPassword=proxyPassword
&proxyAuthMethod=Basic
&authUsername=myUser
&authPassword=myPassword
&authMethod=Basic
&httpClient.authenticationPreemptive=true")
Related
I am using quarkus 1.10.5.Final and need to call web service with web proxy.
Currently my code using microprofile client proxy and put below configuration in application.properties
client/mp-rest/url=https://remote.com
client/mp-rest/scope=javax.inject.Dependent
client/mp-rest/trustStore=classpath:/META-INF/resources/cacerts
client/mp-rest/connectTimeout=5000
client/mp-rest/readTimeout=5000
client/mp-rest/followRedirects=true
client/mp-rest/proxyAddress=http://proxy:8080
but still resulting RESTEASY004655: Unable to invoke request: java.net.UnknownHostException: No such host is known
I tried to use -Dhttp.proxyHost and -Dhttp.proxyPort to test the proxy and it was success.
the problem is I can't use -Dparams since it will break other service calls.
this link where I got config for mp-rest/proxyAddress
https://download.eclipse.org/microprofile/microprofile-rest-client-2.0-RC2/microprofile-rest-client-2.0-RC2.html
but its not mentioned in https://docs.jboss.org/resteasy/docs/4.1.1.Final/userguide/html/MicroProfile_Rest_Client.html
please let me know if I am looking on wrong thing.
May 2021 update
Quarkus 2.0 supports MicroProfile Rest Client 2.0. With it you can use the configuration you mention, namely
# A string value in the form of <proxyHost>:<proxyPort> that specifies the
# HTTP proxy server hostname (or IP address) and port for requests of
# this client to use.
client/mp-rest/proxyAddress=host:port
Or set it programmatically with
ProxiedClient client = RestClientBuilder.newBuilder()
.baseUri(someUri)
.proxyAddress("myproxy.mycompany.com", 8080)
.build(ProxiedClient.class);
Original answer
You should be able to set proxy for your Quarkus Rest client with the following properties:
org.jboss.resteasy.jaxrs.client.proxy.host
org.jboss.resteasy.jaxrs.client.proxy.port
org.jboss.resteasy.jaxrs.client.proxy.scheme
I just run into the same problem and found this issue.
Upgrade to MP Rest Client 2.0 #10520
MP-Rest-Client 2.0 is not available in quarkus 1.10.5.
I am using Apache Camel route for HTTP call. I wanted to add timeout if there is delay from host system.
I am using the following configuration but it is not working. The client request is getting timeout without waiting host system timeout. The client timeout is configured in CXF but the camel timeout is configured in camel route. It should timeout in 4 second and it should go to error processor and but it is not happening.
HTTP
<setHeader headerName="CamelHttpQuery">
<constant>httpclient.soTimeout=4000&bridgeEndpoint=true&throwExceptionOnFailure=false</constant>
<setHeader>
HTTP4
<setHeader headerName="CamelHttpQuery"><constant>httpclient.socketTimout=4000&bridgeEndpoint=true&throwExceptionOnFailure=false</constant>
<setHeader>
Thanks
Please be attentive for syntax. Correct spelling
httpClient.socketTimeout=4000&bridgeEndpoint=true&throwExceptionOnFailure=false
But even after correcting parameters it will not work. Instead of configuring http endpoint you send your parameters as query string of request to server. For set up endpoint just add your parameters to it and use CamelHttpQuery header for request parameters.
So basically, I have made a RESTful API using ServiceTalk from Apple (Netty implementation) and Jersey and it works. Only through http though. I have seen that when I was making my React web page make a POST request through http, it would complain about CORS (which I'm still trying to fix) and that the browser (At least Brave) would not allow the request to be made because it was http and my web page was running on https using let's encrypt cert. How do I fix this issue? Do I need to add SSL with Netty? If so, how can I do that with a certificate that's going to be changing every once in a while?
I also have NGINX setup with Let's Encrypt and enabled auto-renew certificate setting from the setup wizard for NGINX + Let's Encrypt. If I can somehow make NGINX run the HTTPS request as a proxy to the netty server on http, then I think it would also be a better solution. I know this is a common practice with NodeJS Express + NGINX.
You are right, if you already have NGINX that serves your static content (html/css/js) it will be better to configure it as a proxy for a ServiceTalk backend service. That will let you keep SSL/TLS configuration in one place (NGINX config file only) and you will be able to use its auto-renew certificate feature. For an example of how you can configure NGINX as an SSL/TLS proxy for a backend service, see here: https://docs.nginx.com/nginx/admin-guide/security-controls/securing-http-traffic-upstream/
However, in this case, your connection between NGINX and ServiceTalk will not be encrypted. In some environments, it might be inappropriate according to security policies and requirements. If this is your case, you also need to configure SSL/TLS for ServiceTalk using HttpServerBuilder.secure() method that returns HttpServerSecurityConfigurator. Here is an example of a secure ServiceTalk server.
To avoid CORS, keep using NGINX as a proxy even when ServiceTalk also configured with SSL/TLS connections. If there is a requirement to avoid additional proxy on the way between a browser and backend service, target ServiceTalk directly. But NGINX gives additional features, like load balancing between multiple backend instances.
To get the best SSL performance in ServiceTalk/Netty we recommend to use OpenSSL provided instead of a built-in JDK provider. For more information, see Performance / netty-tcnative OpenSSL engine documentation section.
Note: ServiceTalk does not auto-renew SSL/TLS certificates. You will need to restart the server when certificate expires.
I have a Java application which was built with Apache Camel. The application uses Apache Camel to construct an HTTP request to AWS VPC Endpoint.
When the Java application sends out an HTTP request, it receives HTTP Status Code 400 (Bad Request). The VPC Flow Log can be found with the traffic (correct source and destination IP addresses).
On the other hand, if we use curl command to send the same HTTP request, it turns back 200 OK.
What is a possible cause? Is there any configuration in Apache Camel to see what is the exact HTTP content or raw HTTP header/message sent out?
You could check if Content-Type and other mandatory request headers are available at Exchange.in.headers. Just log in.headers within camel-simple tag. I think 400 happening because improper content-type or bad payload.
It might be that you are sending headers that are not allowed by the API since Camel maps message headers automatically to HTTP headers.
Camel's camel-http4 component uses Apache HttpClient 4.x library and you can configure it to log raw http requests.
For instance with log4j you would add to properties:
log4j.logger.org.apache.http=DEBUG
Detailed logging options can be seen from here: https://hc.apache.org/httpcomponents-client-4.5.x/logging.html
I am connecting to a WCF web service with a Java client I am constructing. Someone else has already successfully built WCF clients to connect to this service. The WSDL available via HTTP provides Message Level Security. The WSDL available via HTTPS uses both TLS and Message Level Security. I understand that using TLS on top of Message Level Security is basically dual-encrypting, but that is a key requirement.
Since I can connect to the HTTP service correctly, I believe I have all the trust store and key store issues resolved.
I am connecting to the service using Metro 2.1.1. I have built the client in both Eclipse and Netbeans. I fetch the WSDL from the HTTP site, and using wsimport (with the -extensions flag) I build and execute the clients successfully.
When I fetch the WSDL using the HTTPS site I can again build both clients successfully. But when I execute them - I get the following error:
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: An error occurred when verifying security for the message.
at com.sun.xml.ws.fault.SOAP12Fault.getProtocolException(SOAP12Fault.java:225)
at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:122)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
at $Proxy43.request(Unknown Source)
The only difference between the two WSDLs (the one fetched via HTTP and the other via HTTPS) is the reference in the WSDL to HTTPS:// vs. HTTP://.
I do not have easy access to the WCF service logs - normally there is a 3-6 hour delay between when I request a set of logs and when I can view them.
My question is has anyone encountered a similar circumstance - and is there something I am blatantly missing here? Is there something in a NetMon or Wireshark trace I can look for to see that the issue is? I have been struggling with this for days - any help would be most appreciated.
If you have access to the service configuration try disabling security context on the endpoint you're using:
<message establishSecurityContext="False" clientCredentialType="UserName"/>
You can read more about security context token (SCT):
Security Context Token
Message security knobs
Java client for WCF service with wsHttpBinding over SSL