United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6647956 Browser authenticator not working correctly in new Java Plug-In
JDK-6647956 : Browser authenticator not working correctly in new Java Plug-In

Details
Type:
Bug
Submit Date:
2008-01-08
Status:
Closed
Updated Date:
2010-09-08
Project Name:
JDK
Resolved Date:
2008-01-28
Component:
deploy
OS:
generic,windows_xp
Sub-Component:
plugin
CPU:
x86,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b11)

Related Reports
Relates:

Sub Tasks

Description
The attached test case indicates that the browser authenticator support in the new Java Plug-In is not working correctly. The behavior should be that if the user authenticates to password-protected content using the browser, and then attempts to access the same content via an applet, that the applet should pick up the authentication result from the browser and not prompt the user with an authentication dialog. The behavior observed at least with IE 7 and the new Java Plug-In is that the authentication dialog is presented the first time the password-protected content is accessed from Java even though the user has already authenticated to the browser. This is a regression compared to the old Java Plug-In.

Additionally, at least in IE 7, if "Cancel" is selected in the Java-side authentication dialog, then subsequent attempts to access the content appear to deadlock, apparently due to the pending request not being cleared by the com.sun.deploy.security.DeployAuthenticator.openDialog() method. This is the stack trace for the latter failure:

"thread applet-AuthApplet-2" prio=4 tid=0x0b3dd800 nid=0x3a8 in Object.wait() [0x0bbcf000..0x0bbcfb94]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x03054848> (a java.util.HashMap)
	at java.lang.Object.wait(Object.java:485)
	at sun.net.www.protocol.http.AuthenticationInfo.requestIsInProgress(AuthenticationInfo.java:117)
	- locked <0x03054848> (a java.util.HashMap)
	at sun.net.www.protocol.http.AuthenticationInfo.getServerAuth(AuthenticationInfo.java:258)
	at sun.net.www.protocol.http.HttpURLConnection.getServerAuthentication(HttpURLConnection.java:1640)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1087)
	- locked <0x02a12cf8> (a sun.net.www.protocol.http.HttpURLConnection)
	at AuthApplet.start(AuthApplet.java:20)
	at sun.plugin2.applet.Applet2Manager$AppletExecutionRunnable.run(Applet2Manager.java:1508)
	at java.lang.Thread.run(Thread.java:619)

Note that in order to run the attached test case the content must be served up from an Apache web server with mod_auth enabled and with AllowOverride set to "All" (or a sufficient value) in httpd.conf. Additionally, the authtest/protected/.htaccess file's AuthUserFile needs to be modified to point to the location of the test case's .htpasswd file as unzipped on to the web server.
The deadlock above is reproducible with both the old and new Java Plug-In.
The deadlock above is a separate issue from the browser authenticator not working in the new Java Plug-In and has been filed as 6648001.

                                    

Comments
SUGGESTED FIX

http://sa.sfbay.sun.com/projects/deployment_data/6u10/6647956.0
testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6647956
                                     
2008-01-09
EVALUATION

The browser authenticator was not functioning in the new Java Plug-In
because of a simple and embarrassing backwards null check, causing the
functionality to always be disabled. Because no tests have been run
against this functionality, this problem was not discovered until now.
Thanks to Jess Holle from PTC (a CAP member) for pointing out the
regression and for the description of how to write a test case for
this functionality.

There were additionally a few problems with the new code in the
Firefox plug-in for the browser authenticator. The contract ID was not
correct for the nsIJVMAuthTools. The assert statements in
MozPluginInstance.cpp were never firing, even in debug builds. The
string concatenation of the username and password had an off-by-one
bug where the password was being truncated. On Windows, it is
necessary to use the MSCredentialManager to prevent the authentication
dialog from being popped up even after the authentication information
is obtained from the browser.
                                     
2008-01-09



Hardware and Software, Engineered to Work Together