I'm using the proxy settings in the config to set the host and port
information. I really don't know what I'm doing, just trying to follow what
it seems the DropWizard Configuration Reference seems to implies.
I get the host, port, username, password from the config and then when I'm
building a HttpClient with HttpClientBuilder I pass `.using(config.
getHttpClient())` which should pass the ProxyConfiguration since
HttpClient has a ProxyConfiguration property.
MicroserviceClientConfiguration networksConfig =
config.getnetworksClientConfiguration(); // MicroserviceClientConfiguration is
a class that has two properties, `HttpClientConfiguration httpClient;` and
`String url;`.
ProxyConfiguration proxyConfig =
networksConfig.getHttpClient().getProxyConfiguration();
CredentialsProvider credsProvider = new BasicCredentialsProvider();
credsProvider.setCredentials(
new AuthScope(proxyConfig.getHost(), proxyConfig.getPort()),
new UsernamePasswordCredentials("username", "password")
);
final HttpClient apiHttpClient = new HttpClientBuilder(env)
.using(config.getHttpClient())
.using(credsProvider)
.build("client");
Well, the URL I am hitting has HTTPS, so maybe I should switch the port's
setting to 443.
I just switched the port setting in the config to 8080 and removed the
manual addition of the Authentication header. I just get a 401 in response.
Output from my log:
> DEBUG [2018-10-22 22:30:23,587] com.[project.resources.networksClient:
> Request ->
> method: GET
> allheaders: []
> config: null
> protocolVersion: HTTP/2.0
> requestLine: GET https://host.com/api/networks HTTP/2.0
> uri: https://host.com/api/networks
> ERROR [2018-10-22 22:30:23,924] com.project.resources.networksClient: Unable
> to connect to vendor:
> ! org.apache.http.client.ClientProtocolException: Unexpected response status:
> 401
>
>
On Friday, October 19, 2018 at 3:42:36 PM UTC-4, Dimas Guardado wrote:
>
> Can you say a bit more about what you're trying to do with the proxy
> config? When I run a similar example on my end without the proxy config, it
> behaves the way I expect -- transparently adding an auth header*.
>
> I have a feeling something may be getting lost in the proxy config. It
> looks like you're setting credentials using the proxy's host (host.com)
> and port (8080), but you're making requests out to host.com on port 443.
> I don't think the client is finding any credentials that match an auth
> scope on host.com:443 and so it's not sending an Authorization header
> automatically. Furthermore, you may be clobbering any credentials you have
> configured for your proxy on host.com:8080.
>
> If you're intending to proxy requests to host.com:443 through a proxy on
> host.com:8080, you'll want to make sure your auth scope uses 443 instead
> of 8080.
>
> * What it actually does in this case is sends the request without an
> Authorization header and captures the 401 challenge response, then sends a
> subsequent request with the Authorization header. This should all be
> transparent to the caller, though.
>
> On Thursday, October 18, 2018 at 12:45:21 PM UTC-7, [email protected]
> wrote:
>>
>> Right now, I'm trying to figure out why the Authorization Header is not
>> being created when a HttpClient makes a request.
>>
>> I would have thought defining CredentialsProvider and passing it via
>> *using()* would trigger some logic to auto add the Authorization header
>> into the Request.
>>
>> Unless I misunderstand the purpose of CredentialsProvider.
>>
>> As Dimas mentioned, HttpClient
>> <https://www.dropwizard.io/1.3.5/docs/manual/client.html#apache-httpclient>
>> can
>> be setup. Then used ProxyConfiguration
>> <https://www.dropwizard.io/1.3.5/docs/manual/client.html#proxy-authentication>
>> to
>> set the following configurations:
>>
>> myClient:
>> url: https://host.com/api/
>> httpClient:
>> timeout: 3s
>> connectionTimeout: 3s
>> proxy:
>> host: 'host.com'
>> port: 8080
>> scheme: 'https'
>> auth:
>> username: 'insert-username'
>> password: 'insert-password'
>> authScheme: Basic
>> credentialType: UsernamePassword
>> nonProxyHosts:
>> - 'localhost'
>>
>>
>> So when I do the following:
>>
>> CredentialsProvider credsProvider = new BasicCredentialsProvider();
>> credsProvider.setCredentials(
>> new AuthScope(proxyConfig.getHost(), proxyConfig.getPort()),
>> new UsernamePasswordCredentials("username", "password")
>> );
>>
>> final HttpClient apiHttpClient = new HttpClientBuilder(env)
>> .using(config.getHttpClient())
>> .using(credsProvider)
>> .build("client");
>>
>>
>> When I make a GET call, I notice the Authorization header is missing:
>>
>> HttpGet request = new HttpGet(requestUrl);
>>
>> request.setProtocolVersion(new ProtocolVersion("HTTP", 2, 0));
>>
>> JsonNode response = this.getHttpClient().execute(request,
>> getResponseHandler());
>>
>>
>>
>> So right after the HttpGet is initialized, I have to run
>> request.setHeader(HttpHeaders.AUTHORIZATION, "Basic
>> {encoded-username/password}") in order to ensure the authorization
>> header is there.
>>
>> So that brings me to my assumption that CredentialsProvider (via .using(
>> credsProvider)) would have trigger something that automatically adds the
>> header in the requests.
>>
>>
>> On Thursday, October 18, 2018 at 10:31:45 AM UTC-4, [email protected]
>> wrote:
>>>
>>> Not an API gateway, I am making two microservices that would take
>>> requests forwarded from the client. Then the microservices forward them off
>>> to third-party services.
>>>
>>> The client is supposed to think the microservices has all the
>>> information it needs. The microservices are used to use the client's
>>> desired API and make it look like the third-party services adhere to it.
>>>
>>> It is supposed to be a quick and dirty way to demonstrate the adherence
>>> to a API standard required by the client. As that's what my company wants
>>> to develop and provide to the client.
>>>
>>> On Wednesday, October 17, 2018 at 5:00:46 PM UTC-4, Martin Charlesworth
>>> wrote:
>>>>
>>>> It sounds like you're trying to write your own api gateway. If I were
>>>> you I'd take a look at Netflix Zuul where most of the scaffolding is in
>>>> place for you, before reinventing the wheel.
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.