93403 - java security access when running an applet

Status: CLOSED INVALID

(Core Graveyard :: Java: OJI, defect)

Description

[Pablo A. Salgado]

I'm developing a site and testing it with Netscape 6 under Windows 2000 y
Netscape 6PR1 under  Linux.

Well, the page contains an applet that makes a java.net.URLConnection to a
server and try to perform an HTTP GET method to a Servlet. While Netscape 6 in
Windows works properly. Netscape 6PR1 in Linux generates a java security access.

If you are interested in reproducing bug you can try the sendGetMessage in
HTTPMessage class found in com.oreilly.servlet package (www.servlets.com) in an
applet.

In the other hand here is bit of code that works on both flavours of Netscape:

       java.net.URL url = new java.net.URL(getWebServerURL() + getServlet());
System.out.println("postObjects: " + url);
       java.net.URLConnection con = url.openConnection();
   con.setDoInput(true);
   con.setDoOutput(true);
   con.setUseCaches(false);
   con.setRequestProperty("Content-Type", "application/x-java-serialized-object");

   // Write the arguments as post data
   java.io.ObjectOutputStream out = new
java.io.ObjectOutputStream(con.getOutputStream());
   int numObjects = objs.length;
   for (int x = 0; x < numObjects; x++) {
           out.writeObject(objs[x]);
       }

   out.flush();
   out.close();

   return new java.io.ObjectInputStream(con.getInputStream());

But here is a bit of code that fails on Linux but works on Windows (return line:
con.getInputStream()):

   String argString = "";  // default

   if (args != null) {
     argString = "?" + toEncodedString(args);
   }
   URL url = new URL(servlet.toExternalForm() + argString);
System.out.println("sendGetMessage: " + url);

   // Turn off caching
   URLConnection con = url.openConnection();
   con.setUseCaches(false);

   // Send headers
   sendHeaders(con);

   return con.getInputStream();

I thank you in advance if one of you can help me to workaround this problem

Comment 1

[Con Kolivas]

Not sure if this helps you but the jsse (security for java) is not included by
default with the linux java run time environment.

Comment 2

[Igor Kushnirskiy]

moving to oji

Comment 3

[edburns]

Reassign to Joe as I'm leaving the role of OJI module owner.

Comment 4

[edburns]

Ressign to Joe Chou, as I am no longer working officially on OJI.

Comment 5

[Joe Chou]

Re-assign to sep.

Comment 6

[Sergey Lunegov]

Pablo, could you represent the complete java code that fails on Linux ?
Please describe all steps that I should make to reproduce the bug.

Comment 7

[Sergey Lunegov]

Attachment: testcase

HTML testcase

Comment 8

[Sergey Lunegov]

Attachment: applet testcase

Applet testcase which create instance of HttpMessage and invokes
method sendGetMessage(). After that the obtained InputStream is
checked to be not NULL.

Comment 9

[Sergey Lunegov]

I downloaded package mentioned in the description and create
applet (Attachment #59684 [details]). Applet creates instance of HttpMessage and invokes
method sendGetMessage(). After that the obtained InputStream is
checked to be not NULL. In all cases I got NOT null InputStream.
I tested applet on Mozilla branch 095 on Linux Redhat 6.2 with
JRE1.3.0_01, JRE1.3.1 and JRE1.4.0: applet works.
Then I tested this applet on Linux Redhat 7.1: for all same JREs
APPLETVIEWER displays java security exception. Reporter would you
please tell what Linux release did you use. Anyway from my point of view
this is not Mozilla bug: that maybe specific security java bug for
Linux Redhat 7.1.

Comment 10

[Pablo A. Salgado]

Unfortunetly I lost the code that generated the error because I had to
workaround and that code was never sent to CVS. When I had the error the linux
distribution was Slackware 7.1 running JRE1.3.0 from Sun Microsytems with
Mozilla 0.9.3. I think I could reproduce the error again but I have not enough
time for now. Recently some one here reported a similar problem running
Blackdown JRE 1.3.1 on Slackware 7.1 and Red Hat 7.0

Comment 11

[Sergey Lunegov]

I filed bug number #4533426 against java_security. And I propose
to close this bug as INVALID because this is not Mozilla bug.

Comment 12

[Sergi]

Resolve, going to close as invalid.

Comment 13

[Sergi]

Close as proposed.
Reporter: if you disagree, feel free to reopen.

Comment 14

[Sergey Lunegov]

One more comment. Actually this is not a bug: neither browser bug nor
java bug. In 'your_java.policy' file you should add the following permission:

permission java.net.SocketPermission "site_where_to_connect", "connect";

And then run ControlPanel of your java plugin and add the following runtime
option: -Djava.security.policy='your_java.policy'. Just remember that
you must set full path to 'your_java.policy'.