Bug ID: JDK-4769350 proxy authentication username and password caching only works in serial case

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
1.4.2 mantisFixed

In the attached testcase, it tries to connect to java.sun.com to get 2 files and print it out.  if I set it to go thru a password protected proxy, the serial case will only pop up the password authentication dialog for the first connection, the 2nd connection it will uses the cached password.

but if the test case spawns 2 threads to do the connection, the password auth. dialog will pop up twice and it didn't use the cached username and password.

for serial case:
java -DproxyHost=comanche.sfbay.sun.com -DproxyPort=8080 test serial

for multi thread case:
java -DproxyHost=comanche.sfbay.sun.com -DproxyPort=8080 test mthread

username:  jaws
password:  jawstest

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b08

14-06-2004

EVALUATION It's an application error. If the authenticator provided by the application JAuthenticator wants to provide caching in the multithreaded case, it can do so by adding a cache. Then in the synchronized getPasswordAuthentication() method, it first checks in its cache before popping up the dialog box asking user for information. I will wait for submitter's response before closing it as not a bug. ###@###.### 2002-10-28 I don't think this is an application error. Using the java.net.Authenticator APIs, there is no way for the application to find out whether the username and password is correct or not. So how can I cache the correct password and decide in getPasswordAuthentication() that whether I should pop up the dialog or return the cached correct password? ###@###.### 2002-10-28 Sorry, I was mistaken. Our internal implementation (sun.net.... classes) does provide authentication cache. Although the cache access is synchronized. We currently don't provide synchronization across the whole process of retrieving authentication information (i.e. 1. checking against cache. 2. if no info available, ask the user). I am not sure that's even desirable given that step 2 could take a long time and other processes would be blocked. Further discussion within the team is needed. ###@###.### 2002-10-29 Quoting from Michael: "It's debatable. The problem is that synchronizing the authenticator will not help. Both threads are in the middle of the authentication procedure by the time they call up to the application. You would have to ensure that the first URLConnection (that updates the cache) is single-threaded. That is a reasonable workaround, especially in the case where it is proxy authentication. One solution could be to provide some visibility of the cache to the authenticator so it could use synchronization and decide to back off if the cache has been updated. I think we should consider this in the new HTTP API, and maybe offer something in tiger, but I don't believe we can do anything for mantis. - Michael." --------------------------------------- We are currently investigating a possible solution for mantis ###@###.### 2002-11-07

07-11-2002