Additionally, I had to add the following under *greetingClient:* in the
config.yml
greetingClient:
httpClient:
tls:
verifyHostname: false
trustSelfSignedCertificates: true
On Monday, November 5, 2018 at 2:55:34 PM UTC-5, [email protected] wrote:
>
> I was successful with a modified version of your client.
>
> I had to add the following:
>
> AuthCache authCache = new BasicAuthCache();
> HttpHost targetHost = new HttpHost(baseUri.getHost(), baseUri.getPort(),
> baseUri.getScheme());
> authCache.put(targetHost, new BasicScheme());
>
> // Add AuthCache to the execution context
> final HttpClientContext context = HttpClientContext.create();
> context.setCredentialsProvider(credsProvider);
> context.setAuthCache(authCache);
>
>
> And then pass the context in the `httpClient.execute()` method.
>
> On Monday, November 5, 2018 at 12:41:53 PM UTC-5, [email protected] wrote:
>>
>> Hmm, I see it with your app, but not when I run my app. Instead of:
>>
>> DEBUG [2018-11-02 22:00:22,249]
>> org.apache.http.impl.execchain.MainClientExec: Target auth state: CHALLENGED
>> DEBUG [2018-11-02 22:00:22,249]
>> org.apache.http.impl.auth.HttpAuthenticator: Generating response to an
>> authentication challenge using basic scheme
>> DEBUG [2018-11-02 22:00:22,254]
>> org.apache.http.impl.execchain.MainClientExec: Proxy auth state:
>> UNCHALLENGED
>> DEBUG [2018-11-02 22:00:22,254] org.apache.http.headers: http-outgoing-1
>> >> GET /greeting HTTP/1.1
>> DEBUG [2018-11-02 22:00:22,254] org.apache.http.headers: http-outgoing-1
>> >> Host: dw-basic-auth-example.herokuapp.com
>> DEBUG [2018-11-02 22:00:22,254] org.apache.http.headers: http-outgoing-1
>> >> Connection: Keep-Alive
>> DEBUG [2018-11-02 22:00:22,254] org.apache.http.headers: http-outgoing-1
>> >> User-Agent: Example (greting-client)
>> DEBUG [2018-11-02 22:00:22,254] org.apache.http.headers: http-outgoing-1
>> >> Accept-Encoding: gzip,deflate
>> DEBUG [2018-11-02 22:00:22,254] org.apache.http.headers: http-outgoing-1
>> >> Authorization: Basic LOOOOONNGGG
>>
>>
>> I got this:
>>
>> DEBUG [2018-11-02 22:09:53,127]
>> org.apache.http.impl.execchain.MainClientExec: Target auth state:
>> UNCHALLENGED
>>
>> DEBUG [2018-11-02 22:09:53,127]
>> org.apache.http.impl.execchain.MainClientExec: Proxy auth state: UNCHALLENGED
>>
>> DEBUG [2018-11-02 22:09:53,128] org.apache.http.headers: http-outgoing-0 >>
>> GET /api/data HTTP/1.1
>>
>> DEBUG [2018-11-02 22:09:53,128] org.apache.http.headers: http-outgoing-0 >>
>> Host: host.com
>>
>> DEBUG [2018-11-02 22:09:53,128] org.apache.http.headers: http-outgoing-0 >>
>> Connection: Keep-Alive
>>
>> DEBUG [2018-11-02 22:09:53,128] org.apache.http.headers: http-outgoing-0 >>
>> User-Agent: networks-service (networks-client)
>>
>> DEBUG [2018-11-02 22:09:53,128] org.apache.http.headers: http-outgoing-0 >>
>> Accept-Encoding: gzip,deflate
>>
>>
>> So the authorization header is not added, but also the Target auth state
>> is Unchallenged
>>
>> On Friday, November 2, 2018 at 4:01:03 PM UTC-4, Dimas Guardado wrote:
>>>
>>> So, an Authorization header *is* added to the HTTP request that is
>>> ultimately sent over the wire. However, the Authorization header *is not*
>>> automatically added to the request object that is created in the
>>> GreetingClient (there's not really a mechanism for that, since we're just
>>> calling the HttpGet constructor).
>>>
>>> You can see the headers that are sent over the wire by enabling
>>> http-client's header logging. You can enable header logging by adding the
>>> following to the logging.loggers stanza of your config.yml
>>>
>>> ```
>>> org.apache.http: DEBUG
>>> ```
>>>
>>>
>>> Once enabled, you should see a log line that looks like this when
>>> requests are sent:
>>>
>>> ```
>>> DEBUG [2018-11-02 19:43:04,947] org.apache.http.headers: http-outgoing-6
>>> >> Authorization: Basic base64encodedcreds
>>> ```
>>>
>>> (You'll also see the challenge request/response cycle that is otherwise
>>> hidden from the GreetingClient)
>>>
>>> I've updated the project with the header logging here:
>>> https://github.com/dguardado/dw-http-client-example/commit/aacfe2c1987a56a8a93cca0d588dd367701b6f49
>>>
>>> Are you able to see those header log lines on your end?
>>>
>>> On Friday, November 2, 2018 at 12:27:02 PM UTC-7, [email protected]
>>> wrote:
>>>>
>>>> Forgot to add a link to the branch with the changes to print out the
>>>> contents I had listed:
>>>> https://github.com/Stargator/dw-http-client-example/tree/master
>>>>
>>>> On Friday, November 2, 2018 at 1:45:45 PM UTC-4, [email protected]
>>>> wrote:
>>>>>
>>>>> Hey Dimas,
>>>>>
>>>>> I forked your project and I tested it out. It does *not* seem to
>>>>> automatically add an Authorization header to the request:
>>>>>
>>>>> 0:0:0:0:0:0:0:1 - - [02/Nov/2018:17:25:12 +0000] "GET /check-greeting
>>>>> HTTP/1.1" 200 29 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1)
>>>>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36"
>>>>> 1229
>>>>> 0:0:0:0:0:0:0:1 - - [02/Nov/2018:17:25:12 +0000] "GET /favicon.ico
>>>>> HTTP/1.1" 404 43 "http://localhost:8080/check-greeting"; "Mozilla/5.0
>>>>> (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like
>>>>> Gecko)
>>>>> Chrome/70.0.3538.67 Safari/537.36" 5
>>>>> DEBUG [2018-11-02 17:25:17,917]
>>>>> tech.dimas.example.client.GreetingClient: Request Line: GET
>>>>> https://dw-basic-auth-example.herokuapp.com/greeting HTTP/1.1
>>>>> DEBUG [2018-11-02 17:25:17,917]
>>>>> tech.dimas.example.client.GreetingClient: Config: null
>>>>> DEBUG [2018-11-02 17:25:17,917]
>>>>> tech.dimas.example.client.GreetingClient: URI:
>>>>> https://dw-basic-auth-example.herokuapp.com/greeting
>>>>> DEBUG [2018-11-02 17:25:17,917]
>>>>> tech.dimas.example.client.GreetingClient: Protocol Version: HTTP/1.1
>>>>> DEBUG [2018-11-02 17:25:17,917]
>>>>> tech.dimas.example.client.GreetingClient: Headers: []
>>>>> 0:0:0:0:0:0:0:1 - - [02/Nov/2018:17:25:18 +0000] "GET /check-greeting
>>>>> HTTP/1.1" 200 29 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1)
>>>>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36"
>>>>> 178
>>>>>
>>>>>
>>>>> Though the authentication still seems to be processed successfully.
>>>>> That helps answer my question about whether the Authorization is suppose
>>>>> to
>>>>> be auto-added.
>>>>>
>>>>> On Wednesday, October 31, 2018 at 10:57:45 AM UTC-4, [email protected]
>>>>> wrote:
>>>>>>
>>>>>> Thanks, I'll look at that. I appreciate the responses, thanks Dimas.
>>>>>>
>>>>>> On Friday, October 26, 2018 at 1:08:35 AM UTC-4, Dimas Guardado wrote:
>>>>>>>
>>>>>>> I'm not sure if there's an existing example out there, but I created
>>>>>>> a quick-and-dirty example here:
>>>>>>>
>>>>>>> https://github.com/dguardado/dw-http-client-example
>>>>>>>
>>>>>>> Let me know if you have any questions!
>>>>>>>
>>>>>>> On Wednesday, October 24, 2018 at 7:43:20 AM UTC-7,
>>>>>>> [email protected] wrote:
>>>>>>>>
>>>>>>>> Same result without the header being manually defined. I get a 401
>>>>>>>> status code in the response.
>>>>>>>>
>>>>>>>> This is what I have in my config file now:
>>>>>>>>
>>>>>>>> url: https://host.com/api/
>>>>>>>> host: 'host.com'
>>>>>>>> port: 443
>>>>>>>> username: 'username'
>>>>>>>> password: 'password'
>>>>>>>> authScheme: Basic
>>>>>>>> httpClient:
>>>>>>>> timeout: 3s
>>>>>>>> connectionTimeout: 3s
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This is how I use data from the configuration file in the *run*
>>>>>>>> function
>>>>>>>> to setup BaseAuthentication:
>>>>>>>>
>>>>>>>> UsernamePasswordCredentials userCreds = new
>>>>>>>> UsernamePasswordCredentials(config.getUsername(),
>>>>>>>> config.getPassword());
>>>>>>>>
>>>>>>>>
>>>>>>>> CredentialsProvider credsProvider = new BasicCredentialsProvider();
>>>>>>>> credsProvider.setCredentials(
>>>>>>>> new AuthScope(config.getHost(), config.getPort(), null,
>>>>>>>> config.getAuthScheme()),
>>>>>>>> userCreds);
>>>>>>>>
>>>>>>>> final HttpClient apiHttpClient = new HttpClientBuilder(env)
>>>>>>>> .using(config.getHttpClient()) // returns a
>>>>>>>> HttpClientConfiguration object
>>>>>>>> .using(credsProvider)
>>>>>>>> .build("networks-client");
>>>>>>>>
>>>>>>>> NetworksClient fwdNetworksClient = new NetworksClient(apiHttpClient,
>>>>>>>> config.getUrl());
>>>>>>>>
>>>>>>>>
>>>>>>>> Is there a working example that sets up Basic Authentication for a
>>>>>>>> DropWizard client and then makes a request that automatically has the
>>>>>>>> authorization header set?
>>>>>>>>
>>>>>>>> On Tuesday, October 23, 2018 at 1:56:43 PM UTC-4, [email protected]
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I'll give it a shot!
>>>>>>>>>
>>>>>>>>> On Tuesday, October 23, 2018 at 12:38:58 PM UTC-4, Dimas Guardado
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> What happens if you try removing the proxy configuration
>>>>>>>>>> altogether? Your curl command seems to work fine without a proxy
>>>>>>>>>> (unless
>>>>>>>>>> you have that configured elsewhere). If you're only using the proxy
>>>>>>>>>> config
>>>>>>>>>> so you can pass host/port values to your auth scope, and you're not
>>>>>>>>>> intending to proxy your requests through a proxy server, you may end
>>>>>>>>>> up
>>>>>>>>>> with a misconfigured client.
>>>>>>>>>>
>>>>>>>>>> On Monday, October 22, 2018 at 4:14:29 PM UTC-7,
>>>>>>>>>> [email protected] wrote:
>>>>>>>>>>>
>>>>>>>>>>> I can use curl successfully to get a response from the vendor's
>>>>>>>>>>> API as seen below.
>>>>>>>>>>>
>>>>>>>>>>> I would like to have my DropWizard client do the same thing, use
>>>>>>>>>>> the username and password to define the Authorization header's
>>>>>>>>>>> value. Set
>>>>>>>>>>> the Authorization Header, use SSL, and use HTTP/2
>>>>>>>>>>>
>>>>>>>>>>> curl --user 'username:password' -k "
>>>>>>>>>>>>> https://host.com/api/networks"; -H "accept: application/json"
>>>>>>>>>>>>> --verbose
>>>>>>>>>>>>
>>>>>>>>>>>> * Trying 32.270.19.44...
>>>>>>>>>>>>
>>>>>>>>>>>> * TCP_NODELAY set
>>>>>>>>>>>>
>>>>>>>>>>>> * Connected to host.com (32.270.19.44) port 443 (#0)
>>>>>>>>>>>>
>>>>>>>>>>>> * ALPN, offering h2
>>>>>>>>>>>>
>>>>>>>>>>>> * ALPN, offering http/1.1
>>>>>>>>>>>>
>>>>>>>>>>>> * Cipher selection:
>>>>>>>>>>>>> ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
>>>>>>>>>>>>
>>>>>>>>>>>> * successfully set certificate verify locations:
>>>>>>>>>>>>
>>>>>>>>>>>> * CAfile: /etc/ssl/cert.pem
>>>>>>>>>>>>
>>>>>>>>>>>> CApath: none
>>>>>>>>>>>>
>>>>>>>>>>>> * TLSv1.2 (OUT), TLS handshake, Client hello (1):
>>>>>>>>>>>>
>>>>>>>>>>>> * TLSv1.2 (IN), TLS handshake, Server hello (2):
>>>>>>>>>>>>
>>>>>>>>>>>> * TLSv1.2 (IN), TLS handshake, Certificate (11):
>>>>>>>>>>>>
>>>>>>>>>>>> * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
>>>>>>>>>>>>
>>>>>>>>>>>> * TLSv1.2 (IN), TLS handshake, Server finished (14):
>>>>>>>>>>>>
>>>>>>>>>>>> * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
>>>>>>>>>>>>
>>>>>>>>>>>> * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
>>>>>>>>>>>>
>>>>>>>>>>>> * TLSv1.2 (OUT), TLS handshake, Finished (20):
>>>>>>>>>>>>
>>>>>>>>>>>> * TLSv1.2 (IN), TLS change cipher, Client hello (1):
>>>>>>>>>>>>
>>>>>>>>>>>> * TLSv1.2 (IN), TLS handshake, Finished (20):
>>>>>>>>>>>>
>>>>>>>>>>>> * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
>>>>>>>>>>>>
>>>>>>>>>>>> * ALPN, server accepted to use h2
>>>>>>>>>>>>
>>>>>>>>>>>> * Server certificate:
>>>>>>>>>>>>
>>>>>>>>>>>> * subject: CN=host.com
>>>>>>>>>>>>
>>>>>>>>>>>> * start date: Jun 3 00:00:00 2018 GMT
>>>>>>>>>>>>
>>>>>>>>>>>> * expire date: Jul 3 12:00:00 2019 GMT
>>>>>>>>>>>>
>>>>>>>>>>>> * issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
>>>>>>>>>>>>
>>>>>>>>>>>> * SSL certificate verify ok.
>>>>>>>>>>>>
>>>>>>>>>>>> * Using HTTP2, server supports multi-use
>>>>>>>>>>>>
>>>>>>>>>>>> * Connection state changed (HTTP/2 confirmed)
>>>>>>>>>>>>
>>>>>>>>>>>> * Copying HTTP/2 data in stream buffer to connection buffer
>>>>>>>>>>>>> after upgrade: len=0
>>>>>>>>>>>>
>>>>>>>>>>>> * Server auth using Basic with user 'username'
>>>>>>>>>>>>
>>>>>>>>>>>> * Using Stream ID: 1 (easy handle 0x7ff1c200a400)
>>>>>>>>>>>>
>>>>>>>>>>>> > GET /api/networks HTTP/2
>>>>>>>>>>>>
>>>>>>>>>>>> > Host: fwd.app
>>>>>>>>>>>>
>>>>>>>>>>>> > Authorization: Basic
>>>>>>>>>>>>> bNWtYUhvbl3qb2huGQJhaC5jb206UcIqbSpRSoghIQ==
>>>>>>>>>>>>
>>>>>>>>>>>> > User-Agent: curl/7.54.0
>>>>>>>>>>>>
>>>>>>>>>>>> > accept: application/json
>>>>>>>>>>>>
>>>>>>>>>>>> >
>>>>>>>>>>>>
>>>>>>>>>>>> RESPONSE:
>>>>>>>>>>>
>>>>>>>>>>>> * Connection state changed (MAX_CONCURRENT_STREAMS updated)!
>>>>>>>>>>>>
>>>>>>>>>>>> < HTTP/2 200
>>>>>>>>>>>>
>>>>>>>>>>>> < date: Mon, 22 Oct 2018 23:05:59 GMT
>>>>>>>>>>>>
>>>>>>>>>>>> < content-type: application/json;charset=utf-8
>>>>>>>>>>>>
>>>>>>>>>>>> < set-cookie:
>>>>>>>>>>>>> AWSALB=Ri8qyaECWXb2r8xTbFLAbG+pUXkAQr8gGTZiqfnpUl94pzHwF81jPMTfbEhp4oE58uVeeZi4gMkS7jyiELKiup+ouQCdzzRSygg+DSLSHG6/qL9sI2M;
>>>>>>>>>>>>>
>>>>>>>>>>>>> Expires=Mon, 29 Oct 2018 23:05:59 GMT; Path=/
>>>>>>>>>>>>
>>>>>>>>>>>> < x-content-type-options: nosniff
>>>>>>>>>>>>
>>>>>>>>>>>> < x-xss-protection: 1; mode=block
>>>>>>>>>>>>
>>>>>>>>>>>> < cache-control: no-cache, no-store, max-age=0, must-revalidate
>>>>>>>>>>>>
>>>>>>>>>>>> < pragma: no-cache
>>>>>>>>>>>>
>>>>>>>>>>>> < expires: 0
>>>>>>>>>>>>
>>>>>>>>>>>> < strict-transport-security: max-age=31536000 ;
>>>>>>>>>>>>> includeSubDomains
>>>>>>>>>>>>
>>>>>>>>>>>> < x-frame-options: DENY
>>>>>>>>>>>>
>>>>>>>>>>>> < vary: Accept-Encoding, User-Agent
>>>>>>>>>>>>
>>>>>>>>>>>> < server: Jetty(9.4.z-SNAPSHOT)
>>>>>>>>>>>>
>>>>>>>>>>>> <
>>>>>>>>>>>>
>>>>>>>>>>>> * Connection #0 to host host.com left intact
>>>>>>>>>>>>
>>>>>>>>>>>> [{"id":"2275","name":"demo","orgId":"992","creatorId":"2050"}]
>>>>>>>>>>>>
>>>>>>>>>>>>
--
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.
