Unable to open HTTP connection from Applet when called from JavaScript



Core Graveyard
Java: OJI
17 years ago
7 years ago


(Reporter: udoo, Assigned: Xiaobin Lu)


Windows NT

Firefox Tracking Flags

(Not tracked)



(6 attachments)



17 years ago
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

17 years ago
Created attachment 29444 [details]

Comment 2

17 years ago
Created attachment 29445 [details]

Comment 3

17 years ago
Created attachment 29446 [details]
*** Bug 74363 has been marked as a duplicate of this bug. ***
this is not a blocker.
changing serverity.
Severity: blocker → major

Comment 6

17 years ago
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:


On Unix that would be


I'm marking this wontfix at Stanley's request.
Last Resolved: 17 years ago
Resolution: --- → WONTFIX

Comment 7

17 years ago
I put the line     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 
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 
Resolution: WONTFIX → ---

Comment 8

17 years ago
You restarted the browser after updating HOSTS?

Comment 9

17 years ago
Created attachment 31208 [details]
Tar.gz of testcase that works with trunk.

Comment 10

17 years ago

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?


Comment 11

17 years ago
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:     p49985.wdf.sap-ag.de


Comment 12

17 years ago
Marking NEW while you guys work on it.
Ever confirmed: true

Comment 13

17 years ago
Are you still getting the AccessControlException?

You have the correct steps for installing another JVM uebrigens.

Comment 14

17 years ago
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

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


Assignee: edburns → xiaobin.lu
Priority: -- → P3

Comment 16

17 years ago
Currently Javascript call Java crashes the browser.(See 82034 for details). I 
will come back when 82034 fixed. Marking blocked by 82034.
Depends on: 82034

Comment 17

17 years ago
     Please apply the latest patch for 82034. It works for me now.


Comment 18

17 years ago
 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

17 years ago
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, 

Comment 20

17 years ago
   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.
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 21

17 years ago
Hi Xiaobin, 

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


Comment 22

17 years ago
    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

17 years ago
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 :-(


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

17 years ago
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

17 years ago
QA Contact: shrir → pmac

Comment 26

17 years ago
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

17 years ago
Created attachment 47394 [details]
Screen shot to demonstrate the alert dialog

Comment 28

17 years ago
Created attachment 47395 [details]
Screen shot to demonstrate the alert dialog

Comment 29

17 years ago
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. 


Comment 30

17 years ago
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

17 years ago
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

17 years ago
Thanks Xiaobin. Marking verified.


7 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.