rburgst/okhttp-digest

Problem with "previous basic authentication failed, returning null"

SailReal opened this issue ยท 15 comments

Thanks four your hard work to making this repo possible!

I've a question using the okhttp-digest for authentication:
Connecting to a specific server (https://www.pcloud.com/) I'm getting often (not always) 401 responses while presenting the correct credentials, around every randomly 5 request using the same setup.

Often during the communiction with this server I get an an W/OkHttp: previous basic authentication failed, returning null in the log but everything seems to be fine. Only if after that, a Cached authentication expired. Sending a new request. and followed again by a previous basic authentication failed, returning null appears in the log, the server responds with a 401.

03-10 10:24:10.586 5144-5180 W/OkHttp: previous basic authentication failed, returning null
03-10 10:24:10.586 5144-5180 D/OkHttp: Cached authentication expired. Sending a new request.
03-10 10:24:10.916 5144-5180 W/OkHttp: previous basic authentication failed, returning null

Can you imagine what I'm doing wrong or is just the server bad configured? Communicating with other servers I'm facing no errors and never saw this logs before.

The complete HTTP-response when this error happen:

D	20180308141040.447	OkHttp	<-- 401 Unauthorized https://webdav.pcloud.com/[_path_] (411ms)
D	20180308141040.448	OkHttp	Date: Thu, 08 Mar 2018 20:10:41 GMT
D	20180308141040.449	OkHttp	Server: Apache/2.4.10 (Debian)
D	20180308141040.450	OkHttp	Keep-Alive: timeout=5, max=98
D	20180308141040.455	OkHttp	Connection: Keep-Alive
D	20180308141040.463	OkHttp	<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Unauthorized</title>
</head><body>
<h1>Unauthorized</h1>
<p>This server could not verify that you
are authorized to access the document
requested.  Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
<hr>
<address>Apache/2.4.10 (Debian) Server at webdav.pcloud.com Port 443</address>
</body></html>

THANKS!

hey, I would need a transcript of the whole conversation (i.e. the cases where the messages previous auth failed, cached auth expired were being logged) to better understand whats going on.

Attached the log file: log.txt

If I can provide more information please let me know.

the log unfortunately does not contain the network calls and security headers. Please make sure that you configure the logger as a network interceptor and make sure that all headers (specifically Authorization) are logged.

https://github.com/square/okhttp/wiki/Interceptors

also, the log message comes from the BasicAuthenticator somehow it seems that you are not using the digest authenticator? In case you provide the log containing BASIC authentication, you will probably want to mask the Authorization header as it will contain an unencrypted username/password. Just replace the Basic authentication header with some gibberish (but make sure its the same when the original headers are the same, too).

Yea sorry, using an LogginIntercepter which hides the sensitive data...here is a log using the mentioned Interceptor: log.txt. As mentioned before, sometimes it is working without problems:
log.txt

We from the client side are supporting both, the BasicAuthenticator and the DigestAuthenticator.

sorry to be a pain in the back but I do need to see all the headers along with the response codes.

what I find strange is that the following request

03-11 10:27:01.668 7128-7179/ I/okhttp: Sending request https://webdav.pcloud.com/0/testVault/d/6W/JTCD5CJCIZHSOUL77ZOEO2M3JWCTV6 on null

doesnt appear to contain an auth header

but the response seems to be successful anyway

03-11 10:27:02.338 7128-7179/ I/okhttp: Received response for https://webdav.pcloud.com/0/testVault/d/6W/JTCD5CJCIZHSOUL77ZOEO2M3JWCTV6 in 670.4ms

also the response does contain an WWW-Auth... header however, the client still comes back with an auth header.

03-11 10:27:02.339 7128-7179/ I/okhttp: Sending request https://webdav.pcloud.com/0/testVault/d/6W/JTCD5CJCIZHSOUL77ZOEO2M3JWCTV6/ on null
...
                                                       Authorization: Basic foo==

Somehow this doesnt add up.

Everything fine ๐Ÿ˜„ but I used the mentioned logging interceptor and that interceptor should log all headers or?

Request request = chain.request();

long t1 = System.nanoTime();

Timber.tag("okhttp").i(String.format("Sending request %s on %s%n%s",
		request.url(), chain.connection(), request.headers()));

Response response = chain.proceed(request);

long t2 = System.nanoTime();
Timber.tag("okhttp").i(String.format("Received response for %s in %.1fms%n%s",
		response.request().url(), (t2 - t1) / 1e6d, response.headers()));

return response;

In principle this doesnt look wrong, however, i typically use the following https://github.com/square/okhttp/tree/master/okhttp-logging-interceptor

With the new interceptor, it looks pretty the same ๐Ÿ˜… : log.txt

Is there an example project? When I'm trying to show the login UI dialog after a previous login failure I also get into trouble with the "previous basic authentication failed, returning null".
Is there a code sample I can use to validate I have the correct OKHttp3 connection configured?

@SailReal you did not configure the interceptor as a networkInterceptor

03-12 14:55:23.868 10923-10958/ W/OkHttp: previous basic authentication failed, returning null
03-12 14:55:25.500 10923-10958/ W/OkHttp: previous basic authentication failed, returning null
03-12 14:55:25.500 10923-10958/ D/OkHttp: Cached authentication expired. Sending a new request.

these log lines show that there were multiple roundtrips being made but they didnt end up in the log. Please configure the interceptor as a network interceptor.

check the following code:

client = builder
                    .authenticator(new CachingAuthenticatorDecorator(authenticator, authCache))
                    .addInterceptor(new AuthenticationCacheInterceptor(authCache))
==>              .addNetworkInterceptor(logger)
                    .build();

@rburgst - is your comment for me? I'm using a singleton of the DispatchingAuthenticator because I have both Basic and Digest. When I give Digest a bad username and password I can't get the app to display the dialog again. There is a warning from oktthp3
W/OkHttp: previous basic authentication failed, returning null

The basic authentication scheme is working. It shows the dialog again and again in case of error and login can be canceled by the user. However, the Digest scheme does not work that way. The authenticator code to display the username/password dialog fragment is not triggered a second time. I spent a bunch of hours on it now and it looks like the app triggers the webview mechanism (onReceivedHttpAuthRequest) in the loaded page if the scheme is digest and the first attempt to authenticate fails. Do you have any suggestions? Do you know a way to get the app back to okhttp3 if the auth request is triggered in webview when the link is tapped the second time?

My stuff is complicated by resource sharing between the Basic and Digest schemes that means uninstall is required between tests. My app also requires dynamic setting of credentials so I extended the Credentials object and set up a CredentialsProvider interface.
#41
It doesn't seem to matter whether or not I set up the Interceptor. With or without the AuthenticationCacheInterceptor configuration, Basic works and Digest doesn't.

I appreciate the help. Again, a reference project for this library to help developers connect UX points that go along with the authentication transactions (e.g. login success message) could be useful.

@emezias no, the response was for @SailReal, I would suggest that you open a different ticket since it sounds like your problem is a different one. Please also provide a code sample of how you setup the ok http client.

Thanks a lot for your feedback @rburgst!

Unfortunately I'm not able to reproduce this error anymore using pCloud. Will close this issue because it seems like they fixed something on the server side...thanks again for your help ๐Ÿ˜„