-
Bug
-
Resolution: Fixed
-
P3
-
6
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-2199038 | 7 | Thomas Ng | P3 | Resolved | Fixed | b64 |
FULL PRODUCT VERSION :
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
A DESCRIPTION OF THE PROBLEM :
Our applet running under 1.5 is a signed applet that connects to IP
video cameras and uses basic authentication for userid password. The
IP video cameras are basically http 1.0 web servers where you load a
particular URL you will get back a JPEG. With the recent autoupdate to
1.6 our applet no longer works. We have included a test case of code
with a header dump of the TCPIP traffic under both 1.5 and 1.6. Please
review the code and the HTTP session. The problem is that under 1.6
calls to the class HttpURLConnection and method setRequestProperty
are not being honored. This is required to set the userid and password
for basic authentication. This is very clear in the TCP output
included in the orginal post. We have also identified that if you go
to the Java 1.6 control panel and select Temporary Internet
Files-Settings and uncheck Keep Temporary files on my computer then
our applet will work under 1.6. The difference is probably in the
class loader used to set security when the applet is downloaded versus
the class loader that load the file from local cache and the
appropriate security policy. This is not an acceptable solution as we
need the ability to cache applets or have a one time download.
We do not get any security exceptions or errors in the console from
the java runtime.
We are currently testing setting different policies for the .Net
permissions which may be required under 1.6 to add to the HTTP Header.
This is either a security hole in 1.5 that is now fixed in 1.6 or a
bug in the security manager under 1.6. Either way we need guidance on
exactly what 1.6 is expecting regarding security for application code
to set the HTTP header in a signed applet and why the behavior is
different when cached or not-cached.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Steps can be followed in sample code for the applet.
This bug is now occurring at our customer locations based on the auto-update from 1.5 to 1.6
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
You should be able to set the request property for basic authentication in a signed applet. In the actual results the TCP transactions were captured for Java 1.5 applet where it works, Java 1.6 applet where it doesn't work and a Java 1.6 application where it does work.
If you turn off caching for applets in Java control panel then the Java 1.6 applet works. This is probably a problem with the security manager is different if the jar is loaded from a web server versus loaded from local cache
ACTUAL -
HTTP Requset/Response running as an applet by using jre 1.5.0_10
GET /jpg/1/image.jpg? HTTP/1.1
Content-Type: image/jpeg
Authorization: Basic cm9vdDpzcDEy
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.5.0_10
Host: 127.0.0.1:9900
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
HTTP/1.0 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Connection: close
Content-Type: image/jpeg
Content-Length: 46142
HTTP Requset/Response running as an applet by using jre 1.6.0_01
GET /jpg/1/image.jpg? HTTP/1.1
accept-encoding: gzip
Host: 127.0.0.1:9900
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_01
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
HTTP/1.1 401 Unauthorized
Date: Tue, 08 May 2007 15:30:04 GMT
Accept-Ranges: bytes
Connection: close
WWW-Authenticate: Basic realm="/"
Content-Type: text/html; charset=ISO-8859-1
<HTML><HEAD><TITLE>401 Unauthorized</TITLE></HEAD>
<BODY><H1>401 Unauthorized</H1>
Your client does not have permission to get URL /jpg/1/image.jpg from this server.
</BODY></HTML>
HTTP Requset/Response running as a java application using 1.6
GET /jpg/1/image.jpg? HTTP/1.1
Content-Type: image/jpeg
Authorization: Basic cm9vdDpzcDEy
User-Agent: Java/1.6.0_01
Host: 127.0.0.1:9900
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
HTTP/1.0 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Connection: close
Content-Type: image/jpeg
Content-Length: 45869
ERROR MESSAGES/STACK TRACES THAT OCCUR :
No crash and no exceptions from security manager. The error is silent. The output in the actual results shows the header information is not set in 1.6 applet
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
Source code example for a signed applet
package com.vp;
import java.awt.Container;
import javax.swing.JDesktopPane;
import java.net.HttpURLConnection;
import java.net.URL;
import org.apache.commons.codec.binary.Base64;
public class SimpleTest extends javax.swing.JApplet {
public SimpleTest() {}
public void init() {
try {
String strUrl = "http://192.168.200.31/jpg/1/image.jpg?";
URL urlConn = new URL(strUrl);
HttpURLConnection huc = (HttpURLConnection)urlConn.openConnection();
String admin = "root";
String password = "sp12";
huc.setRequestProperty("Content-Type", "image/jpeg");
huc.setRequestProperty("Authorization", getBasic(admin, password));
huc.setRequestMethod("GET");
huc.setDoInput(true);
// get response
System.out.println("response code: " + huc.getResponseCode());
System.out.println("response message: " + huc.getResponseMessage());
System.out.println("content type: " + huc.getContentType());
} catch (Exception e) {
e.printStackTrace();
}
}
public void start() {
System.out.println("Starting image applet...");
}
public void stop() {
System.out.println("Stopping image applet...");
}
private String getBasic(String user, String password) {
String authBasic = "Basic ";
try {
String userpass = user + ":" + password;
byte[] encoding = Base64.encodeBase64(userpass.getBytes("ISO-8859-1"));
authBasic += new String(encoding, 0, encoding.length, "US-ASCII");
} catch(Exception e) {
e.printStackTrace();
}
return authBasic;
}
public static void main(String[] arg) {
new SimpleTest().init();
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Setting in Java control panel to disable caching of applets as temporary internet files.
Release Regression From : 5.0u11
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_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
A DESCRIPTION OF THE PROBLEM :
Our applet running under 1.5 is a signed applet that connects to IP
video cameras and uses basic authentication for userid password. The
IP video cameras are basically http 1.0 web servers where you load a
particular URL you will get back a JPEG. With the recent autoupdate to
1.6 our applet no longer works. We have included a test case of code
with a header dump of the TCPIP traffic under both 1.5 and 1.6. Please
review the code and the HTTP session. The problem is that under 1.6
calls to the class HttpURLConnection and method setRequestProperty
are not being honored. This is required to set the userid and password
for basic authentication. This is very clear in the TCP output
included in the orginal post. We have also identified that if you go
to the Java 1.6 control panel and select Temporary Internet
Files-Settings and uncheck Keep Temporary files on my computer then
our applet will work under 1.6. The difference is probably in the
class loader used to set security when the applet is downloaded versus
the class loader that load the file from local cache and the
appropriate security policy. This is not an acceptable solution as we
need the ability to cache applets or have a one time download.
We do not get any security exceptions or errors in the console from
the java runtime.
We are currently testing setting different policies for the .Net
permissions which may be required under 1.6 to add to the HTTP Header.
This is either a security hole in 1.5 that is now fixed in 1.6 or a
bug in the security manager under 1.6. Either way we need guidance on
exactly what 1.6 is expecting regarding security for application code
to set the HTTP header in a signed applet and why the behavior is
different when cached or not-cached.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Steps can be followed in sample code for the applet.
This bug is now occurring at our customer locations based on the auto-update from 1.5 to 1.6
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
You should be able to set the request property for basic authentication in a signed applet. In the actual results the TCP transactions were captured for Java 1.5 applet where it works, Java 1.6 applet where it doesn't work and a Java 1.6 application where it does work.
If you turn off caching for applets in Java control panel then the Java 1.6 applet works. This is probably a problem with the security manager is different if the jar is loaded from a web server versus loaded from local cache
ACTUAL -
HTTP Requset/Response running as an applet by using jre 1.5.0_10
GET /jpg/1/image.jpg? HTTP/1.1
Content-Type: image/jpeg
Authorization: Basic cm9vdDpzcDEy
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.5.0_10
Host: 127.0.0.1:9900
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
HTTP/1.0 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Connection: close
Content-Type: image/jpeg
Content-Length: 46142
HTTP Requset/Response running as an applet by using jre 1.6.0_01
GET /jpg/1/image.jpg? HTTP/1.1
accept-encoding: gzip
Host: 127.0.0.1:9900
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_01
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
HTTP/1.1 401 Unauthorized
Date: Tue, 08 May 2007 15:30:04 GMT
Accept-Ranges: bytes
Connection: close
WWW-Authenticate: Basic realm="/"
Content-Type: text/html; charset=ISO-8859-1
<HTML><HEAD><TITLE>401 Unauthorized</TITLE></HEAD>
<BODY><H1>401 Unauthorized</H1>
Your client does not have permission to get URL /jpg/1/image.jpg from this server.
</BODY></HTML>
HTTP Requset/Response running as a java application using 1.6
GET /jpg/1/image.jpg? HTTP/1.1
Content-Type: image/jpeg
Authorization: Basic cm9vdDpzcDEy
User-Agent: Java/1.6.0_01
Host: 127.0.0.1:9900
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
HTTP/1.0 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Connection: close
Content-Type: image/jpeg
Content-Length: 45869
ERROR MESSAGES/STACK TRACES THAT OCCUR :
No crash and no exceptions from security manager. The error is silent. The output in the actual results shows the header information is not set in 1.6 applet
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
Source code example for a signed applet
package com.vp;
import java.awt.Container;
import javax.swing.JDesktopPane;
import java.net.HttpURLConnection;
import java.net.URL;
import org.apache.commons.codec.binary.Base64;
public class SimpleTest extends javax.swing.JApplet {
public SimpleTest() {}
public void init() {
try {
String strUrl = "http://192.168.200.31/jpg/1/image.jpg?";
URL urlConn = new URL(strUrl);
HttpURLConnection huc = (HttpURLConnection)urlConn.openConnection();
String admin = "root";
String password = "sp12";
huc.setRequestProperty("Content-Type", "image/jpeg");
huc.setRequestProperty("Authorization", getBasic(admin, password));
huc.setRequestMethod("GET");
huc.setDoInput(true);
// get response
System.out.println("response code: " + huc.getResponseCode());
System.out.println("response message: " + huc.getResponseMessage());
System.out.println("content type: " + huc.getContentType());
} catch (Exception e) {
e.printStackTrace();
}
}
public void start() {
System.out.println("Starting image applet...");
}
public void stop() {
System.out.println("Stopping image applet...");
}
private String getBasic(String user, String password) {
String authBasic = "Basic ";
try {
String userpass = user + ":" + password;
byte[] encoding = Base64.encodeBase64(userpass.getBytes("ISO-8859-1"));
authBasic += new String(encoding, 0, encoding.length, "US-ASCII");
} catch(Exception e) {
e.printStackTrace();
}
return authBasic;
}
public static void main(String[] arg) {
new SimpleTest().init();
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Setting in Java control panel to disable caching of applets as temporary internet files.
Release Regression From : 5.0u11
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.
- backported by
-
JDK-2199038 setRequestProperty does not work for HttpURLConnection in applet when cached
-
- Resolved
-