Re: [9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed

Hi Max, Please see inline. On 10/16/2015 05:18 AM, Wang Weijun wrote: Let's go back to the bug description: But no fallback happens if: 1. an HTTP server supports both Negotiate (via Kerberos) and Basic authentication schemes 2. first, a user provides correct Kerberos credentials, and a

Re: [9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed

Hi Max, RFC 2617 [1] requires a user agent to use one of the challenges with the strongest auth scheme it understands (please see section 1.2): ... The user agent MUST choose to use one of the challenges with the strongest auth-scheme it understands and request credentials from the

Re: [9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed

Let's go back to the bug description: But no fallback happens if: 1. an HTTP server supports both Negotiate (via Kerberos) and Basic authentication schemes 2. first, a user provides correct Kerberos credentials, and a connection is successfully established with Negotiate scheme 3. then, a

Re: [9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed

> On Oct 7, 2015, at 11:51 PM, Artem Smotrakov > wrote: > > Hi Max, > > HttpURLConnection obtains credentials for HTTP authentication from > Authenticator [1] implementation. Only one authenticator can be set in JVM > instance. It can have built-in credentials,

[9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed

Hello, Please review this for 9. According to [1], an HTTP client should try to use another HTTP authentication scheme if negotiate process failed for some reason, and a user didn't specify SPNEGO or Kerberos in "http.auth.preference" system property. But no fallback happens if, for example:

Re: [9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed

Hi Sean, Sure, it may be useful to print it out. I will update the webrev. Artem On 10/07/2015 05:28 PM, Seán Coffey wrote: Thanks for handling Artem. I'll leave the main review to someone more knowledgeable with http authentication schemes but can I suggest that your print the

Re: [9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed

I will look into this. Busy on something else at the moment. Do you think this would happen in reality? There weren't a lot of fallback in HTTP auth, IMO, is that because in most cases username and password are the same for all schemes, and if one fails, we believe the pair is wrong and there

Re: [9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed

Thanks for handling Artem. I'll leave the main review to someone more knowledgeable with http authentication schemes but can I suggest that your print the AuthenticationHeader.authPref string out with the "Negotiate process failed, fallback" logger message. It's a useful variable to capture.

Re: [9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed

Please see updated webrev http://cr.openjdk.java.net/~asmotrak/8138953/webrev.01/ Artem On 10/07/2015 06:51 PM, Artem Smotrakov wrote: Hi Max, HttpURLConnection obtains credentials for HTTP authentication from Authenticator [1] implementation. Only one authenticator can be set in JVM

Re: [9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed

Hi Max, HttpURLConnection obtains credentials for HTTP authentication from Authenticator [1] implementation. Only one authenticator can be set in JVM instance. It can have built-in credentials, or do some interactions with user to get them. Theoretically, it can provide different credentials