Digest Authentication failing with Dispatching Authenticator

[rburgst]

Digest Authentication failing with Dispatching Authenticator

[emezias]

Here's the short version - My webapp/hybrid needs to dispatch (support both Basic and Digest) and needs to set dynamic credentials. The UX for the credentials is the same dialog fragment for any type of http authentication.

It looks like I'm diving into the authenticator code.
@rburgst Do you have any advice?

[rburgst]

can you add the network logging interceptor and then add comments into the log where you did what?
e.g.

1. enter wrong credentials
   ... HTTP LOG ...
2. change credentials
   ... HTTP LOG ...

[emezias]

ok - here's the play-by-play. First, a test for success:
03-15 13:12:28.227 13384-13496/com.modolabs.kand211.test D/OKGoInterceptor: response code 504
03-15 13:12:28.336 13384-13496/com.modolabs.kand211.test D/OkHttp: --> GET https://jigsaw.w3.org/HTTP/Basic/ h2
03-15 13:12:28.354 13384-13496/com.modolabs.kand211.test D/OkHttp: <-- 401 https://jigsaw.w3.org/HTTP/Basic/ (17ms, 261-byte body)
03-15 13:12:28.355 13384-13496/com.modolabs.kand211.test E/OKGoCachingAuthenticator: no credentials
03-15 13:12:28.358 13384-13384/com.modolabs.kand211.test D/HttpAuthDialog: create http auth dialog
03-15 13:12:28.358 13384-13496/com.modolabs.kand211.test E/OKGoFragmentCallback: callback failure HttpAuthException: https://jigsaw.w3.org/HTTP/Basic/
03-15 13:12:50.829 13384-13384/com.modolabs.kand211.test D/OKGoCachingAuthenticator: request from Dialog basic
03-15 13:12:50.830 13384-13384/com.modolabs.kand211.test D/OKGoConnection: auth request
03-15 13:12:50.831 13384-13496/com.modolabs.kand211.test D/OkHttp: --> GET https://jigsaw.w3.org/HTTP/Basic/ h2
03-15 13:12:50.854 13384-13496/com.modolabs.kand211.test D/OkHttp: <-- 200 https://jigsaw.w3.org/HTTP/Basic/ (22ms, 458-byte body)
03-15 13:12:50.867 13384-13496/com.modolabs.kand211.test D/OKGoInterceptor: response code 200
03-15 13:12:51.263 13384-13384/com.modolabs.kand211.test D/OKBrowserTypeClient: https://jigsaw.w3.org/HTTP/Basic/ finished

Great - my custom authentication class is configured and works correctly. Next test, give it a bad username-password:
03-15 13:17:30.283 14394-14527/com.modolabs.kand211.test D/OKGoInterceptor: response code 504
03-15 13:17:30.308 14394-14527/com.modolabs.kand211.test D/OkHttp: --> GET https://jigsaw.w3.org/HTTP/Basic/ h2
03-15 13:17:30.375 14394-14527/com.modolabs.kand211.test D/OkHttp: <-- 401 https://jigsaw.w3.org/HTTP/Basic/ (66ms, 261-byte body)
03-15 13:17:30.375 14394-14527/com.modolabs.kand211.test E/OKGoCachingAuthenticator: no credentials
03-15 13:17:30.375 14394-14527/com.modolabs.kand211.test E/OKGoFragmentCallback: callback failure HttpAuthException: https://jigsaw.w3.org/HTTP/Basic/
03-15 13:17:30.378 14394-14394/com.modolabs.kand211.test D/HttpAuthDialog: create http auth dialog
03-15 13:17:46.126 14394-14394/com.modolabs.kand211.test D/OKGoCachingAuthenticator: https://jigsaw.w3.org/HTTP/Basic/ setting credentials? ydydydy:ufucufyc
03-15 13:17:46.126 14394-14394/com.modolabs.kand211.test D/OKGoCachingAuthenticator: request from Dialog basic
03-15 13:17:46.127 14394-14394/com.modolabs.kand211.test D/OKGoConnection: auth request
03-15 13:17:46.128 14394-14527/com.modolabs.kand211.test D/OkHttp: --> GET https://jigsaw.w3.org/HTTP/Basic/ h2
03-15 13:17:46.141 14394-14527/com.modolabs.kand211.test D/OkHttp: <-- 401 https://jigsaw.w3.org/HTTP/Basic/ (12ms, 261-byte body)
03-15 13:17:46.141 14394-14527/com.modolabs.kand211.test W/OkHttp: previous basic authentication failed, returning null
03-15 13:17:46.141 14394-14527/com.modolabs.kand211.test E/OKGoCachingAuthenticator: bad credentials? ydydydy:ufucufyc

The authentication failure is correct. As expected, my app recreates the authentication dialog fragment. The retry is here - intercepted by my interceptor - OKGoInterceptor, not the AuthenticationCacheInterceptor. Two interceptors are configured and the AuthenticationCacheInterceptor is first. The connection client setup was pasted into this issue previously.

03-15 13:17:46.141 14394-14527/com.modolabs.kand211.test D/OKGoInterceptor: response code 401
03-15 13:17:46.142 14394-14527/com.modolabs.kand211.test E/HttpAuthDialog: http authentication failure HttpAuthException: https://jigsaw.w3.org/HTTP/Basic/
03-15 13:17:46.158 14394-14394/com.modolabs.kand211.test D/HttpAuthDialog: create http auth dialog
Now I pass the correct credentials
03-15 13:23:32.590 14394-14394/com.modolabs.kand211.test D/OKGoCachingAuthenticator: https://jigsaw.w3.org/HTTP/Basic/ setting credentials? guest:guest
03-15 13:23:32.590 14394-14394/com.modolabs.kand211.test D/OKGoCachingAuthenticator: request from Dialog basic
03-15 13:23:32.590 14394-14394/com.modolabs.kand211.test W/OkHttp: previous basic authentication failed, returning null
03-15 13:23:32.590 14394-14394/com.modolabs.kand211.test W/OkHttp: previous basic authentication failed, returning null

and that’s the end - The BasicAuthenticator never returns a new request to send to the connection client so the dialog pops up again. This is the simplest case. My custom authenticator is configured and it correctly calls the BasicAuthenticator and that Authenticator does not read the new credentials.

[emezias]

(Here's a brief history of the circles I've run around)

First I set up my custom authenticator with a singleton DispatchingAuthenticator. Any call to authenticate in my custom class was answered by the DispatchingAuthenticator and it passed the test for success. This broke down in case of an error and retry.

Next I tried my own dispatching, created singletons for the Basic and Digest auth objects. I put them in a cache for the AuthenticationCacheInterceptor and handled things as before. Now the authenticate method in my class is calling either basic or digest. Again the test for success is good.

Last thing I did before getting into the library issues window was to create a new Authenticator (Basic or Digest) with every call so I could be sure the latest credentials were set. No change - still getting null back when I need a new request object. I took the AuthenticationCacheInterceptor out because I thought it might be holding the old Authenticator with the bad credentials. When I tried again, still no luck.

Do I need to rebuild the request nested inside the response? It should be clear that I get the same results for digest as I do for basic. Thanks in advance for any help you might offer to trace the problem. I thought the plan for my code - to use a singleton DispatchingAuthenticator was going to do the job. The dynamic credentials seem to be the problem I cannot solve without your help. Thanks again for looking into it.

[emezias]

OK - sorry - I had to step away and do some other things. Now let me try that again. Here's the Header level logging.

1. Tap the Basic Authentication page link and open the connection

03-21 17:09:35.354 15665-15765/test D/OKGoInterceptor: response code 504
03-21 17:09:35.442 15665-15765/test D/OkHttp: --> GET https://jigsaw.w3.org/HTTP/Basic/ h2
03-21 17:09:35.442 15665-15765/test D/OkHttp: X-Kurogo-BaseURL: https://ks211-test.modolabs.net/ks
03-21 17:09:35.442 15665-15765/test D/OkHttp: X-Kurogo-Device: small-android-native
03-21 17:09:35.442 15665-15765/test D/OkHttp: User-Agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MPA44I; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/65.0.3325.109 Mobile Safari/537.36 KurogoVersion/2.10 (Kurogo Android) KurogoOSVersion/6.0 KurogoAppVersion/2.10.0 (test)
03-21 17:09:35.442 15665-15765/test D/OkHttp: X-Kurogo-Navigation-Version: 3
03-21 17:09:35.442 15665-15765/test D/OkHttp: Referer: https://ks211-test.modolabs.net/ks/launchpad/index?_kgourl_type=web
03-21 17:09:35.442 15665-15765/test D/OkHttp: Cache-Control: no-cache
03-21 17:09:35.442 15665-15765/test D/OkHttp: Host: jigsaw.w3.org
03-21 17:09:35.442 15665-15765/test D/OkHttp: Connection: Keep-Alive
03-21 17:09:35.442 15665-15765/test D/OkHttp: Accept-Encoding: gzip
03-21 17:09:35.442 15665-15765/test D/OkHttp: --> END GET
03-21 17:09:35.455 15665-15765/test D/OkHttp: <-- 401 https://jigsaw.w3.org/HTTP/Basic/ (12ms)
03-21 17:09:35.455 15665-15765/test D/OkHttp: date: Wed, 21 Mar 2018 21:09:35 GMT
03-21 17:09:35.455 15665-15765/test D/OkHttp: content-length: 261
03-21 17:09:35.455 15665-15765/test D/OkHttp: content-type: text/html;charset=ISO-8859-1
03-21 17:09:35.455 15665-15765/test D/OkHttp: server: Jigsaw/2.3.0-beta3
03-21 17:09:35.455 15665-15765/test D/OkHttp: www-authenticate: Basic realm="test"
03-21 17:09:35.455 15665-15765/test D/OkHttp: strict-transport-security: max-age=15552015; includeSubDomains; preload
03-21 17:09:35.455 15665-15765/test D/OkHttp: public-key-pins: pin-sha256="cN0QSpPIkuwpT6iP2YjEo1bEwGpH/yiUn6yhdy+HNto="; pin-sha256="WGJkyYjx1QMdMe0UqlyOKXtydPDVrk7sl2fV+nNm1r4="; pin-sha256="LrKdTxZLRTvyHM4/atX2nquX9BeHRZMCxg3cf4rhc2I="; max-age=864000
03-21 17:09:35.455 15665-15765/test D/OkHttp: x-frame-options: deny
03-21 17:09:35.455 15665-15765/test D/OkHttp: x-xss-protection: 1; mode=block
03-21 17:09:35.456 15665-15765/test D/OkHttp: <-- END HTTP

2. Show the dialog to the user to set the credentials

03-21 17:09:35.457 15665-15765/test D/HttpAuthDialog: new instance Basic
03-21 17:09:35.457 15665-15765/test D/OKGoInterceptor: Http Auth https://jigsaw.w3.org/HTTP/Basic/

3. Enter a username and password that fails:

03-21 17:09:44.027 15665-15665/test D/OKGoConnection: auth request
03-21 17:09:44.028 15665-15765/test D/OkHttp: --> GET https://jigsaw.w3.org/HTTP/Basic/ h2
03-21 17:09:44.028 15665-15765/test D/OkHttp: X-Kurogo-BaseURL: https://ks211-test.modolabs.net/ks
03-21 17:09:44.028 15665-15765/test D/OkHttp: X-Kurogo-Device: small-android-native
03-21 17:09:44.028 15665-15765/test D/OkHttp: User-Agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MPA44I; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/65.0.3325.109 Mobile Safari/537.36 KurogoVersion/2.10 (Kurogo Android) KurogoOSVersion/6.0 KurogoAppVersion/2.10.0 (test)
03-21 17:09:44.028 15665-15765/test D/OkHttp: X-Kurogo-Navigation-Version: 3
03-21 17:09:44.028 15665-15765/test D/OkHttp: Referer: https://ks211-test.modolabs.net/ks/launchpad/index?_kgourl_type=web
03-21 17:09:44.028 15665-15765/test D/OkHttp: Authorization: Basic aHhoZGhkOmhkaGRqZg==
03-21 17:09:44.028 15665-15765/test D/OkHttp: Cache-Control: no-cache
03-21 17:09:44.028 15665-15765/test D/OkHttp: Host: jigsaw.w3.org
03-21 17:09:44.028 15665-15765/test D/OkHttp: Connection: Keep-Alive
03-21 17:09:44.028 15665-15765/test D/OkHttp: Accept-Encoding: gzip
03-21 17:09:44.028 15665-15765/test D/OkHttp: --> END GET
03-21 17:09:44.039 15665-15765/test D/OkHttp: <-- 401 https://jigsaw.w3.org/HTTP/Basic/ (11ms)
03-21 17:09:44.039 15665-15765/test D/OkHttp: date: Wed, 21 Mar 2018 21:09:44 GMT
03-21 17:09:44.039 15665-15765/test D/OkHttp: content-length: 261
03-21 17:09:44.039 15665-15765/test D/OkHttp: content-type: text/html;charset=ISO-8859-1
03-21 17:09:44.039 15665-15765/test D/OkHttp: server: Jigsaw/2.3.0-beta4
03-21 17:09:44.040 15665-15765/test D/OkHttp: www-authenticate: Basic realm="test"
03-21 17:09:44.040 15665-15765/test D/OkHttp: strict-transport-security: max-age=15552015; includeSubDomains; preload
03-21 17:09:44.040 15665-15765/test D/OkHttp: public-key-pins: pin-sha256="cN0QSpPIkuwpT6iP2YjEo1bEwGpH/yiUn6yhdy+HNto="; pin-sha256="WGJkyYjx1QMdMe0UqlyOKXtydPDVrk7sl2fV+nNm1r4="; pin-sha256="LrKdTxZLRTvyHM4/atX2nquX9BeHRZMCxg3cf4rhc2I="; max-age=864000
03-21 17:09:44.040 15665-15765/test D/OkHttp: x-frame-options: deny
03-21 17:09:44.040 15665-15765/test D/OkHttp: x-xss-protection: 1; mode=block
03-21 17:09:44.040 15665-15765/test D/OkHttp: <-- END HTTP
03-21 17:09:44.040 15665-15765/test E/OKGoCachingAuthenticator: bad credentials? hxhdhd:hdhdjf
03-21 17:09:44.040 15665-15765/test E/HttpAuthDialog: http authentication failure HttpAuthException: https://jigsaw.w3.org/HTTP/Basic/
03-21 17:09:44.057 15665-15665/test D/HttpAuthDialog: create http auth dialog

4. Dialog to get username and password returns after the failure. *This dialog is passed a response and route so that it has the parameters to authenticate after the user presses the OK button.

This time the input is the correct username and password but pressing ok never goes to the network. The dialog is shown again. Maybe it's because it's the same response as the first dialog?

03-21 17:10:21.666 15665-15665/test D/OKGoCachingAuthenticator: https://jigsaw.w3.org/HTTP/Basic/ setting credentials? guest:guest
03-21 17:10:21.666 15665-15665/test W/OkHttp: previous basic authentication failed, returning null
03-21 17:10:21.666 15665-15665/test W/OkHttp: previous basic authentication failed, returning null
03-21 17:10:21.688 15665-15665/test D/HttpAuthDialog: create http auth dialog

Thanks in advance for having a look at it.

[rburgst]

its very hard for me to see what you are doing in your code after the first authentication fails. The authenticator has a fixed credentials object, therefore, if in the same conversation it gets asked again for providing the credentials then it (IMHO rightfully) believes that sending the same password a 2nd time will not yield better results. Therefore you are seeing the error message.
IMHO if the authentication fails and you want to swap the authenticaiton, you need to setup a new "communication channel" with the server.
Usually you would set up a new OkHttp client with a new authenticator containing the corrected authentication info.

[emezias]

Thanks for the feedback. I can't exactly share the code.

The authenticator configured with the OK client is a custom class. It has BasicAuthenticator and DigestAuthenticator members configured in a ConcurrentHashMap for the Interceptor (like the README).

The code also caches the credentials by URL and by realm. There are 2 HashMap<String, CredentialsProvider> objects in the authenticator leftover from the previous httpurlconnection logic.

After an authentication failure the user is prompted to provide the correct username and password. When the app gets that new username and password - what can I do?

I tried many things to get make a second request. The log I sent is from running code that creates a new BasicAuthenticator object using a new Credentials object to make a second try within the custom class. The code also updates the Cache that was used to create the AuthenticationCacheInterceptor. Tried working on a custom class set as interceptor that extends AuthenticationCacheInterceptor and also tried going without the Interceptor.

It would be great to get a better idea for solving what seems like a common use case. Is the best and only solution to create a new OK Connection client?

[rburgst]

Without seeing your code its really not possible to help you further. I have created a unit test https://github.com/rburgst/okhttp-digest/blob/master/src/test/java/com/burgstaller/okhttp/basic/BasicAuthenticatorWithMockWebserverTest.java#L111 which outlines how the system should work should you change the authentication mid-way.

[emezias]

Extrapolating logic for UX from a background thread test is not quite straightforward.
I found the problem with the BasicAuthenticator. The logic on this line:

https://github.com/rburgst/okhttp-digest/blob/master/src/main/java/com/burgstaller/okhttp/basic/BasicAuthenticator.java#L39

blocks my second attempt from succeeding. The request that is passed to the Authenticator has an Authorization header on it. The call to authenticateWithState is coming from the 401 return code response to the failed attempt, the request that failed has an Authorization header. I have to rebuild that request so there is no Authorization header. The code I got working sets the Authorization header empty every time I call authenticateWithState from the username/password dialog fragment. That's working with Basic - now I have to figure out what to do with Digest. The log shows a problem that is similar to the Basic type except the drop on the second attempt is on the nonce header. "previous digest authentication with same nonce failed, returning null"

[emezias]

Here is the final answer. In this use case, the request inside of the response object with a 401 return code already has an Authorization header because the first attempt to authorize had bad credentials. This means that the library will mistake it for a retry of the previous request. To fix the problem I rebuild the request from the response and clear the Authorization header. Then I rebuild the response with the rebuilt request. Then I call authenticate with the Basic or Digest Authenticator.

Once I figured out the problem was retry logic in my app getting crossed by the retry logic inside the Authenticator it came together. The credentials don't matter, the Authenticator always returns null when it is passed a response from a call that was made with bad credentials.

This issue can become a feature request. Please add a method to allow a CachingAuthenticator reset so that credentials set at runtime will work without logic to rebuild the request inside the response before passing that response to the Authenticator. I'm looking for a neat, clean way to get the Authenticator to accept a call to authenticate with a new response. As it stands, if a response has a request with the "Authorization" header it is assumed the CachingAuthenticator has the same credentials that failed rather than allowing for dynamic, runtime username and password.

[rburgst]

I have added yet another unit test with a digest authenticator and an auth cache interceptor (basically exactly as documented in the readme) and it works exactly like the BASIC authentication case.
YOU SHOULD NOT ATTEMPT to do a retry within your app.
Your app needs to react to the 401 error prompt the user for new credentials. Once the user has entered his new credentials send a copy of the original request (which should obviously not have any previous headers attached).

You can see this in https://github.com/rburgst/okhttp-digest/blob/master/src/test/java/com/burgstaller/okhttp/digest/CachingAuthenticatorWithMockWebserverTest.java#L122
Note that in https://github.com/rburgst/okhttp-digest/blob/master/src/test/java/com/burgstaller/okhttp/digest/CachingAuthenticatorWithMockWebserverTest.java#L140 I create a wholly new request with the same URL.

The credentials don't matter, the Authenticator always returns null when it is passed a response from a call that was made with bad credentials.

This is correct. The authenticator will know that within a request/response cycle the credentials should not have changed, and will therefore not retry sending the same (wrong) credentials.

Changing the credentials within an okhttp request/response cycle which even involves prompting the user for a new password (which typically happens on a completely different thread) and hoping that we can carry on as if nothing has happened is definitely stretching the system beyond its initial design (both mine and that of okhttp).

Creating a new request is a neat clean way of dealing with things. I am not sure what your app is doing and how it injects itself in the response processing but I fear its not a wise choice.

I am using the whole setup in a bunch of my apps and the way I outlined it works like a charm, even if the actual requests are done on background threads, etc.

[rburgst]

So the bottom line is, dont try and involve the user within an interceptor. If the request failed, you should stop the whole request/response cycle, ask the user for a new password, and then create a new request and everything will work as expected.

[emezias]

I'm not sure I understand. The request object is extracted from the response with the 401 return code that is a parameter to the authenticate call. The app closes every response so the request is gone. Is a request from a closed response usable? That's what you want me to keep and reuse, right? Are you saying to add another network transaction so the new call will start from scratch after sending wrong credentials? I'm looking at the second call with changed credentials as a retry from the same client. Going back to the original URL that we know will return a 401 error is somewhat inefficient. I'm not sure if that's the recommendation. Thanks for helping me sort this out.

…

On Sat, Apr 7, 2018, 2:43 AM rburgst ***@***.***> wrote: So the bottom line is, dont try and involve the user within an interceptor. If the request failed, you should stop the whole request/response cycle, ask the user for a new password, and then create a new request and everything will work as expected. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAyqsTzITzEXQgrhals3FLbNXE7AM_ASks5tmGArgaJpZM4Spgxt> .

[emezias]

Let me clarify - this logic is in a custom digest type Authenticator rather than code in an Interceptor.
The failed authentication due to wrong credentials returns a Response object that cannot be passed to the Basic or Digest Authenticator because logic to prevent infinite looping retries is reading the request in that response and exiting before the new credentials get sent in a retry. The only way I can retry is to remove the previously set "Authorization" header that is embedded in the failed response. So I return to the question, the use case, the feature request...

Is there a way to retry authentication with new credentials after an authentication attempt with the wrong credentials in the Authorization header has returned a failure response. The credentials in the Authenticator are changed but the Authenticator will reject the login attempt without actually sending the request based on the contents of the Response parameter in the call to authenticate. Setting dynamic credentials from the user at runtime is the use case. Any feedback or follow up questions on this requested API change is appreciated.

[rburgst]

1. there is no need to subclass anything for normal operation as the unit tests linked above show.
2. without seeing your code its kind of hard to say anything
3. dont try to optimize for the error case, the user will take like 30s to input new credentials etc. Its completely useless to try and avoid a 200ms roundtrip for such a case.

[emezias]

There's no subclass.The bandwidth is a consideration as well as throughput. A new call from the failed response to an authenticated request does not get a request from the Authenticator to send to the auth server. Every request is sent as a new call from the ok client. The original, unauthenticated request is gone. It was part of a closed response that was sent prior to the error with credentials. The response now is from the authenticated request created with the (Basic or Digest) Authenticator that had incorrect credentials. The authenticators return null. What is your suggestion for getting the request with new credentials? Is it retaining the unauthenticated request? Perhaps you can further explain that part of the logic from the test. The mock response may not match the real one or perhaps I'm misunderstanding the test.

…

On Mon, Apr 9, 2018, 12:46 AM rburgst ***@***.***> wrote: 1. there is no need to subclass anything for normal operation as the unit tests linked above show. 2. without seeing your code its kind of hard to say anything 3. dont try to optimize for the error case, the user will take like 30s to input new credentials etc. Its completely useless to try and avoid a 200ms roundtrip for such a case. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAyqsXqTNUXEIiBmHyfHVnYxhNwRR7z3ks5tmuergaJpZM4Spgxt> .

[emezias]

Retaining the original request and reusing it when a response inside the Authenticator already has an Authorization header is one possible solution. In this case, a call to the original URL is sent after modifying the Authenticator's credentials. The app duplicates the error condition inside of the Authenticator in order to get past it. Now the app, the BasicAuthenticator, and the DigestAuthenticator all look have this logic:
response.request().header(DigestAuthenticator.WWW_AUTH_RESP) != null

I will stand by my feature request. The Authenticator should be able to handle this case and re-try. The workaround suggested here forces an extra network call to send the app back to scratch so that the re-authentication with updated credentials can go through the interceptor. Looks like the interceptor brings the network call back to the Authenticator anyway. Why not allow the shortcut for a very common use case -> user-set credentials at runtime?

[rburgst]

While I roughly understand what you need, its very difficult to come up with a generic solution that will satisfy your (and also other peoples` needs) without introducing bugs (such as infinite retries, etc.).

Can you create (or extend one of the existing) unit tests so that it will mimic your apps logic (as well as the server responses).

The 2 tests that exist already should give you a good starting point.
The mocked server responses from the above linked tests do mimic real server responses (at least as accurate as they need to be to trigger the required client functionality).

[emezias]

The problem is changing the credentials and sending a call to "authenticate" on either Dispatcher when the response object originated from a request with an authorization header that does not succeed. The "testAuthenticate_withWrongPassword_shouldNotRepeat" is quite close. The unauthorizedResponse in the setUp of the BasicAuthenticatorWithMockWebserverTest needs to have a request object built in with an authorization header.

This is from the BasicAuthenticatorTest
Request dummyRequest = new Request.Builder()
.url("http://www.google.com")
.header("Authorization", "Basic dXNlcjE6dXNlcjE=")
.get()
.build();
credentials.setUserName("user2");

Now add it to the mockWebserver test scheme.
unauthorizedResponseForDynamicCreds = new MockResponse()
.setResponseCode(401)
.addHeader("WWW-Authenticate", "Basic realm="myrealm"");
.request(dummyRequest)

How do I get that second one to work? It will return null no matter what is in the credentials. The BasicAuthenticatorTest should make it clear that the credentials have nothing to do with it. Calling the authenticate method on either Authenticator object with a Response that has an earlier authentication request causes immediate failure. So my use case is required to duplicate logic from the Authenticators to intercept the call to authenticate and re-route. The library can enable an API to change the credentials and clear the state so that the Authenticators will make a new request with the new username/password values.

[emezias]

My shortcut for the problem in my last comment is to change the header on the request that failed instead of forcing another call to the server.
Another solution is to keep the original request, the one that initiated action in the Authenticator object and to use that to call the Basic or Digest Authenticator for requests that follow a change in credentials.
Repeating the network call to get back a clean request inside a new response also works.

The big picture is support for dynamic credentials. The dialog I present to the user means that the credentials are new. Current logic means that there is no way to get a new authentication request from the Authenticator after a response that has failed due to bad credentials. My solution will modify the failed response to get by the null return value in order to support dynamic values and to be fast and efficient.

Building support for this use case into the library would be great. You might have "DynamicCredentials" along with "Credentials" to provide an API that will retry.

[rburgst]

The thing is that the component must work properly in a multithreaded environment. It's quite difficult to get this working correctly and not introduce infinite retries.

[emezias]

Sorry, I don't see it. The main thread is guarantee. The user's input of the dynamic credentials is on main and is not overlapping with other auth requests in this use case. The logic that allows users to set the credential fields when leaving the the main thread can also handle any background processing that is using the Authenticator until the next call to authenticate. I don't see where there would be another process using that object (on Android) since the authenticator has one credential at any given time. Checking the request header of the response is just one of many ways the library might stop the authentication from looping.

…

On Sun, Apr 22, 2018, 3:15 AM rburgst ***@***.***> wrote: The thing is that the component must work properly in a multithreaded environment. It's quite difficult to get this working correctly and not introduce infinite retries. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAyqsRiTnefhgrBTm3TtjXevTxTwIj3Aks5trC4TgaJpZM4Spgxt> .

[rburgst]

this library will not support callbacks to ask the user for new credentials while a http conversation is going on. Please catch the error, ask the user, then create a new http conversation with a new authenticator.