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.
