74367 - Unable to open HTTP connection from Applet when called from JavaScript

Status: VERIFIED FIXED

(Core Graveyard :: Java: OJI, defect, P3)

Description

[udoo]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.8) Gecko/20010215
BuildID:    Mozilla 0.8; Gecko/20010215

An HTTP connection inside an applet is not possible, when the call comes from
JavaScript. It seems that the security settings are to stringent when a
javascript function calls a public java method. Calling of URL.openStream() (and
simalar methods) results in an AccessControlException: access denied
(java.net.SocketPermission <address> resolve).


Reproducible: Always
Steps to Reproduce:
1) see attached html and java (source and class) files
2) put all files into the same folder 
3) start SimplePhoneBack.html
4) the applet as well as the java console shows the first line of the html
source (due to a http get-request inside the applet start method). 
5) press the button "http get"

Actual Results:  java.security.AccessControlException: access denied
  (java.net.SocketPermission p49985.wdf.sap-ag.de resolve)
  at java.security.AccessControlContext.checkPermission(Unknown Source)
  at java.security.AccessController.checkPermission(Unknown Source)
  at java.lang.SecurityManager.checkPermission(Unknown Source)
  at java.lang.SecurityManager.checkConnect(Unknown Source)
  at sun.plugin.protocol.jdk12.http.HttpURLConnection.connectStep1(Unknown Source)
  at sun.plugin.protocol.jdk12.http.HttpURLConnection.getInputStream(Unknown Source)
  at java.net.URL.openStream(Unknown Source)
  at com.sap.weblab.SimplePhoneBack.httpGet(SimplePhoneBack.java:36)
  at java.lang.reflect.Method.invoke(Native Method)
  at sun.plugin.liveconnect.PrivilegedCallMethodAction.run(Unknown Source)
  at java.security.AccessController.doPrivileged(Native Method)
  at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)


Expected Results:  an alert box with <!-- This is the first line of the html
source -->

This bug report is related to bug #69466
(http://bugzilla.mozilla.org/show_bug.cgi?id=69466) which I posted due to the
same problem. Bug #69466 changed to another problem so I opened this report with
new informations.

Comment 1

[udoo]

Attachment: SimplePhoneBack.html

Comment 2

[udoo]

Attachment: SimplePhoneBack.java

Comment 3

[udoo]

Attachment: SimplePhoneBack.class

Comment 4

[Matthias Versen [:Matti]]

*** Bug 74363 has been marked as a duplicate of this bug. ***

Comment 5

[Matthias Versen [:Matti]]

this is not a blocker.
changing serverity.

Comment 6

[edburns]

I hear from Stanley that the way to work around this bug is to modify the HOSTS 
file on your client machine so that it knows how to look up the required host.

An windows that would be:

C:\WINNT\system32\drivers\etc\HOSTS

On Unix that would be

/ect/hosts

I'm marking this wontfix at Stanley's request.

Comment 7

[udoo]

I put the line
10.18.84.25     p49985.wdf.sap-ag.de
into C:\WINNT\system32\drivers\etc\HOSTS but the sample scenario I posted still 
doesn't work :-(
The web server has a fix IP address so DHCP or simalar problem causer is out of 
question. 
I also tried to use the IP address instead of the DNS name in the code but even 
this doesn't seems to help. 

Therefore I reopened the bug.

Matti lowered the serverity from "blocker" to "major", bur for us it remains a 
blocker. 

Comment 8

[edburns]

You restarted the browser after updating HOSTS?

Comment 9

[edburns]

Attachment: Tar.gz of testcase that works with trunk.

Comment 10

[edburns]

Udo,

Can you please try the attached testcase at your site and see if it works?

I'm using JDK 1.3.1 and it works with that.  Perhaps it's a problem in 1.3.0_01?

Ed

Comment 11

[udoo]

Ed's testcase published. But it still doesn't work :-(

As already mentioned in bug 69466 I'm not sure how to use another JVM with 
Mozilla than the default 1.3.0_01. I installed j2sdk-1_3_1-beta-win.exe and 
copied the files NPJava131.dll, NPJava32.dll, NPOJI600.dll aus jdk1.3.1/jre/bin 
to .../Mozilla/Plugins, is this enough? However my JVM console shows now:

Java(TM) Plug-In: Version 1.3.1
Verwendung der JRE-Version 1.3.1-beta Java HotSpot(TM) Client VM

I restarted the browser after changing the HOSTS. The file contains now the 
entry:
10.18.84.25     p49985.wdf.sap-ag.de


Udo

Comment 12

[Keyser Sose]

Marking NEW while you guys work on it.

Comment 13

[edburns]

Are you still getting the AccessControlException?

You have the correct steps for installing another JVM uebrigens.

Comment 14

[udoo]

I just tried Ed's testcase (id=31208) on Mozilla 0.8.1 (20010323) and 
Java(TM) Plug-In: Version 1.3.1
JRE-Version 1.3.1-beta Java HotSpot(TM) Client VM

I still get the same result:
HTTP connections initiated from inside applet's start method work well while 
the same method called from JavaScript results in an exception:
java.security.AccessControlException: access denied (java.net.SocketPermission 
p49985.wdf.sap-ag.de resolve)

My Hosts file contains an IP address for the server and the .java.policy file 
(I am not sure whether it must be .java.policy or java.policy, therefore I 
store both versions) in my profile directory contains:
grant {
  permission java.security.AllPermission;
};

Comment 15

[edburns]

Xiaobin, this works for me.  Can you install my testcase from 04/17 and try it?

Thanks,

Ed

Comment 16

[Xiaobin Lu]

Currently Javascript call Java crashes the browser.(See 82034 for details). I 
will come back when 82034 fixed. Marking blocked by 82034.

Comment 17

[Xiaobin Lu]

  Reporter:
     Please apply the latest patch for 82034. It works for me now.

Comment 18

[Xiaobin Lu]

 Reporter: It should be fine now. Please get the trunk tomorrow and have it try 
with JRE 1.3. Let me know whether I can close this bug.

Comment 19

[udoo]

Hi Xiaobin, 

yes it works (at least with Mozilla 0.9.1+ i.e. Gecko/20010605).
Thank you very much for your help.

You need definitely JRE 1.3.1 (I wasn't able to get it to run with 1.3.0_01). 
You need also a .java.policy file in your profile directory to relax the
security policies (which isn't nice, because this controverts the "zero
installation feature" of java applets). Can you please tell me, if this behavior
will change or remain?

Kind Regards, 
Udo

Comment 20

[Xiaobin Lu]

Udo:
   You are welcome. The bug you mentioned here is what I am trying to fix now 
(59447). But anyway, I happy to close this bug now. Let me know if you are NOT 
OKAY to close this bug.

Comment 21

[udoo]

Hi Xiaobin, 

the bug is fixed for me. If the security issues are fixed later then I will be 
happy.

Udo

Comment 22

[Xiaobin Lu]

udo:
    I ran your testcase again and I found that I don't need to grant all
permissions in java.policy file and it works fine. Please try without loose any
security check and let me know what happened. Thanks!

Comment 23

[udoo]

Hi Xiaobin,

I tried without and with an empty .java.policy and it doesn't work
(AccessControlException during address resolution). I haven't yet the time to
find the minimal security settings that are necesary to initiate an
applet-to-server connection from JavaScript, so I grant all permissions in the
.java.policy file :-(

Udo

By the way: is it possible that the nightly builds deny a http connection to a
server on port 1080? I always get a popup with the message "Access to the port
number given has been disabled for security reasons" and i wasn't able to
deactivate this restriction. This hapens only when I use the nightly build
Gecko/20010605. Mozilla 0.9 alias Gecko/20010505 works fine ?-|

Comment 24

[Xiaobin Lu]

udo: Thanks for your infor! I am sorry that I don't know the answer about your 
questions. Please post it to newsgroup n.p.m.gerneral.

Comment 25

[shrirang khanzode]

qa->pmac

Comment 26

[Patty Mac]

Hi Udoo, I'm quite new to this area.  Based on your  comments "Expected Results:
 an alert box with <!-- This is the first line of the html
source -->",  there is an alert dialog pops up but different message, It does
not say  "This is the first line of the html". I will attach the screen shot for
 showing the alert message different from yours.
Could you confirm this bug again, please? Thanks!

Comment 27

[Patty Mac]

Attachment: Screen shot to demonstrate the alert dialog

Comment 28

[Patty Mac]

Attachment: Screen shot to demonstrate the alert dialog

Comment 29

[udoo]

Hi Patty, 
I still get "AccessControlException: access denied (java.lang.SocketPermission 
hostxyz resolve)", when I hit the "http get" button. The first http request 
which is initiated by the applet's start method is successfull. 

Ciao, 
Udo

Comment 30

[Patty Mac]

Thanks very much for your quick respond, undo! So based on your verifications,
the status of this bug should be "re-opened" instead of "resolved" right?

Comment 31

[Xiaobin Lu]

pmac and Udo:
   Please download the JRE1.4 from java.sun.com/j2se. It should work fine. We 
should not reopen this bug.

Comment 32

[Patty Mac]

Thanks Xiaobin. Marking verified.