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.

Reply via email to