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.
