Interesting, I'm glad this works! I'm not sure I understand why though ¯\_(ツ)_/¯
I'd be curious to see if you can get it working by applying some of the changes you made in isolation. If so, that might help uncover what the underlying issue is. Have you tried running only with the TLS config changes, but without the AuthCache changes? That might indicate the issue is tls verification. If it only seems to work with the AuthCache changes (Pre-emptive authentication), then something might be up with the challenge interaction with the server. Adding the auth cache will send an Authorization header directly without first getting a 401 challenge response. On Monday, November 5, 2018 at 2:11:59 PM UTC-8, [email protected] wrote: > > 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.
