-
Bug
-
Resolution: Won't Fix
-
P3
-
None
-
6u10
-
x86
-
windows_xp
FULL PRODUCT VERSION :
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Windows XP
EXTRA RELEVANT SYSTEM CONFIGURATION :
Site users SSL, RMI tunneling and basic authentication.
A DESCRIPTION OF THE PROBLEM :
On a site that uses SSL users are required to reauthenticate for applets. User accounts consist of a domain prefix, slash and username (TEST\user). When prompted for applet re-authentication the user enters their domain prefix account and clicks Ok. The login box reappears requiring the user to re-authenticate. This goes on until the user finally decides to cancel the applet. Logs indicate that the domain prefix of the username is being stripped, which forces the web server to try and authenticate the userid againsts its own domain instead of the user's domain. Even if the domain user is created as a local account the user is still unable to authenticate for the applet because of domain prefix stripping. In Java 1.5 the stripping of domain prefixes does not occur, but in any 1.6 version it does. Why does Java 1.6 strip domain prefixes?
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. System that uses SSL.
2. Web server uses a local ldap for authentication.
3. Create a local account that users a domain prefix (TEST\user).
4. Create a basic applet.
5. Login to the site and access the applet. Verify that you must re-authenticate for the applet.
6. Enter the domain prefixed account and verify that you are unable to successfully authenticate for the applet even after multiple attempts.
7. Check the Apache error log and verify that the domain prefix is being stripped and the userid alone is being used for authentication.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Domain prefixed accounts should be able to successfully authenticate against applets. Apache logs should indicate that the current userid up for authentication is "TEST\user", not the stipped userid "user'. The applet should NOT strip the domain prefix from a userid. In Java 1.5 domain prefixed accounts are able to successfully authenticate but in 1.6 they are not.
ACTUAL -
When reauthenticating for an applet with a domain prefixed account the domain portion of the userid is stripped. An authenticating user "TEST\user" is stripped down so that the user name passed to the webserver is "user" instead of the whole userid "TEST\user".
ERROR MESSAGES/STACK TRACES THAT OCCUR :
Apache error logs for domain prefix userid "ISSEXT\wchill".
[2308] auth_ldap authenticate: using URL ldap://<host_name>:389/ou=people,cn=AdministrativeLdap,cn=Windchill_9.1,o=ptc
[warn] [2308] auth_ldap authenticate: user wchill authentication failed; URI /Windchill/servlet/WindchillAuthGW/wt.httpgw.HTTPAuthentication/login [User not found][No Such Object]
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
-----------------------------------
AppletTest.1.html
-----------------------------------
<html>
<body>
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="100%" height="100%"
codebase="https://java.sun.com/update/1.6.0/jinstall-6u18-windows-i586.cab#Version=1,6,0,18">
<param name="java_code" value="test/TestApplet.class">
<param name="java_codebase" value="..">
<param name="type" value="application/x-java-applet;version=1.6">
<param name="progressbar" value="true">
<param name="MAYSCRIPT" value="true">
<param name="url" value="https://jessh203l.ptcnet.ptc.com/PDMLinkX20/test/testResource.txt">
<COMMENT>
<EMBED type="application/x-java-applet;version=1.6" width="100%" height="100%"
MAYSCRIPT=true pluginspage="https://java.sun.com/getjava/download.html" java_code="test/TestApplet.class" java_codebase=".."
url="https://jessh203l.ptcnet.ptc.com/PDMLinkX20/test/testResource.txt"
progressbar="true"
><NOEMBED>
</COMMENT>
</NOEMBED></EMBED>
</OBJECT>
</body>
</html>
-----------------------------------
TestApplet.java
-----------------------------------
package test;
import java.awt.BorderLayout;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.net.URL;
import java.net.URLConnection;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.swing.JApplet;
import javax.swing.JScrollPane;
import javax.swing.JTextArea;
public final class TestApplet
extends JApplet
{
private static Logger logger = Logger.getLogger( TestApplet.class.getName() );
private JTextArea textArea = new JTextArea();
private URL url;
@Override
public void init()
{
super.init();
textArea = new JTextArea();
final JScrollPane scrollPane = new JScrollPane( textArea );
setLayout( new BorderLayout() );
add( scrollPane, BorderLayout.CENTER );
final String urlString = getParameter( "url" );
try
{
url = new URL( urlString );
}
catch ( Exception e )
{
logger.log( Level.WARNING, "Invalid URL: " + urlString, e );
}
}
@Override
public void start()
{
final StringBuilder builder = new StringBuilder();
try
{
final URLConnection connection = url.openConnection();
final InputStream inputStream = connection.getInputStream();
try
{
final InputStreamReader reader = new InputStreamReader( inputStream, "UTF-8" );
try
{
final char buffer[] = new char[8*1024];
int nCharsRead;
while ( (nCharsRead = reader.read( buffer )) != -1 )
builder.append( buffer, 0, nCharsRead );
}
finally
{
reader.close();
}
}
finally
{
inputStream.close();
}
}
catch ( Exception e )
{
logger.log( Level.WARNING, "Failed to fetch URL: " + url, e );
}
textArea.setText( builder.toString() );
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
There is no workaround for this issue. If a domain prefixed user can NOT successfully reauthenticate for an applet the user is unable to use the applet thus restricting their access and functionality on the site.
Release Regression From : 5
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Windows XP
EXTRA RELEVANT SYSTEM CONFIGURATION :
Site users SSL, RMI tunneling and basic authentication.
A DESCRIPTION OF THE PROBLEM :
On a site that uses SSL users are required to reauthenticate for applets. User accounts consist of a domain prefix, slash and username (TEST\user). When prompted for applet re-authentication the user enters their domain prefix account and clicks Ok. The login box reappears requiring the user to re-authenticate. This goes on until the user finally decides to cancel the applet. Logs indicate that the domain prefix of the username is being stripped, which forces the web server to try and authenticate the userid againsts its own domain instead of the user's domain. Even if the domain user is created as a local account the user is still unable to authenticate for the applet because of domain prefix stripping. In Java 1.5 the stripping of domain prefixes does not occur, but in any 1.6 version it does. Why does Java 1.6 strip domain prefixes?
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. System that uses SSL.
2. Web server uses a local ldap for authentication.
3. Create a local account that users a domain prefix (TEST\user).
4. Create a basic applet.
5. Login to the site and access the applet. Verify that you must re-authenticate for the applet.
6. Enter the domain prefixed account and verify that you are unable to successfully authenticate for the applet even after multiple attempts.
7. Check the Apache error log and verify that the domain prefix is being stripped and the userid alone is being used for authentication.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Domain prefixed accounts should be able to successfully authenticate against applets. Apache logs should indicate that the current userid up for authentication is "TEST\user", not the stipped userid "user'. The applet should NOT strip the domain prefix from a userid. In Java 1.5 domain prefixed accounts are able to successfully authenticate but in 1.6 they are not.
ACTUAL -
When reauthenticating for an applet with a domain prefixed account the domain portion of the userid is stripped. An authenticating user "TEST\user" is stripped down so that the user name passed to the webserver is "user" instead of the whole userid "TEST\user".
ERROR MESSAGES/STACK TRACES THAT OCCUR :
Apache error logs for domain prefix userid "ISSEXT\wchill".
[2308] auth_ldap authenticate: using URL ldap://<host_name>:389/ou=people,cn=AdministrativeLdap,cn=Windchill_9.1,o=ptc
[warn] [2308] auth_ldap authenticate: user wchill authentication failed; URI /Windchill/servlet/WindchillAuthGW/wt.httpgw.HTTPAuthentication/login [User not found][No Such Object]
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
-----------------------------------
AppletTest.1.html
-----------------------------------
<html>
<body>
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="100%" height="100%"
codebase="https://java.sun.com/update/1.6.0/jinstall-6u18-windows-i586.cab#Version=1,6,0,18">
<param name="java_code" value="test/TestApplet.class">
<param name="java_codebase" value="..">
<param name="type" value="application/x-java-applet;version=1.6">
<param name="progressbar" value="true">
<param name="MAYSCRIPT" value="true">
<param name="url" value="https://jessh203l.ptcnet.ptc.com/PDMLinkX20/test/testResource.txt">
<COMMENT>
<EMBED type="application/x-java-applet;version=1.6" width="100%" height="100%"
MAYSCRIPT=true pluginspage="https://java.sun.com/getjava/download.html" java_code="test/TestApplet.class" java_codebase=".."
url="https://jessh203l.ptcnet.ptc.com/PDMLinkX20/test/testResource.txt"
progressbar="true"
><NOEMBED>
</COMMENT>
</NOEMBED></EMBED>
</OBJECT>
</body>
</html>
-----------------------------------
TestApplet.java
-----------------------------------
package test;
import java.awt.BorderLayout;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.net.URL;
import java.net.URLConnection;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.swing.JApplet;
import javax.swing.JScrollPane;
import javax.swing.JTextArea;
public final class TestApplet
extends JApplet
{
private static Logger logger = Logger.getLogger( TestApplet.class.getName() );
private JTextArea textArea = new JTextArea();
private URL url;
@Override
public void init()
{
super.init();
textArea = new JTextArea();
final JScrollPane scrollPane = new JScrollPane( textArea );
setLayout( new BorderLayout() );
add( scrollPane, BorderLayout.CENTER );
final String urlString = getParameter( "url" );
try
{
url = new URL( urlString );
}
catch ( Exception e )
{
logger.log( Level.WARNING, "Invalid URL: " + urlString, e );
}
}
@Override
public void start()
{
final StringBuilder builder = new StringBuilder();
try
{
final URLConnection connection = url.openConnection();
final InputStream inputStream = connection.getInputStream();
try
{
final InputStreamReader reader = new InputStreamReader( inputStream, "UTF-8" );
try
{
final char buffer[] = new char[8*1024];
int nCharsRead;
while ( (nCharsRead = reader.read( buffer )) != -1 )
builder.append( buffer, 0, nCharsRead );
}
finally
{
reader.close();
}
}
finally
{
inputStream.close();
}
}
catch ( Exception e )
{
logger.log( Level.WARNING, "Failed to fetch URL: " + url, e );
}
textArea.setText( builder.toString() );
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
There is no workaround for this issue. If a domain prefixed user can NOT successfully reauthenticate for an applet the user is unable to use the applet thus restricting their access and functionality on the site.
Release Regression From : 5
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.