Applet can't connect to own host (in Firefox)

Miscellaneous Topics
#1

I had an applet hosted on IP address xx.xx.xx.xx, and the applet could do a
URL(“http://xx.xxx.xx.xx/resource”).openConnection() and do I/O without problems.

Now I have the applet hosted on domain www.abcdef.com which resolves to xx.xx.xx.xx, yet
URL(“http://www.abcdef.com/resource”).openConnection() works fine in MSIE, but fails in Firefox with:


java.security.AccessControlException: access denied (java.net.SocketPermission xx.xx.xx.xx:80)

I think Firefox turns the domain into its IP-address… then checks whether or not “xx.xx.xx.xx” textually equals “www.abcdef.com” ???

This is such a common case, that I’m wondering why I fail to get it right…

#2

I fail to see what the browser has to do with the runtime ?
are they using the same jre when the applet is running ?

does the ip match for both www.abcdef.com and abcdef.com ?

#3

Thanks for replying.

I fail to see it too… yet it only throws an Exception in Firefox

(it’s like Opera doesn’t properly load *.jar.pack.gz while you’d say that’s up to the JRE as well…)

Yup, same version, not JRE process ofcourse.

Yes. At first it wasn’t, so I changed the DNS and did a “ipconfig /flushdns” followed by “ping abcdef.com” to verify the (restarted) browser would see the right IP. Anyway, it resolved to xx.xx.xx.xx anyway, which is the right IP.

#4 

System.out.println(applet.getCodeBase());
--> "http://www.abcdef.com/"

String action = applet.getCodeBase() + "resource/";
URL url = new URL(action);
URLConnection con = url.openConnection();

con.setDoInput(true);
con.setUseCaches(false);

if(postData != null)
{
   con.setDoOutput(true);
   con.getOutputStream().write(postData); // this throws AccessControlException: access denied (SocketPermission xx.xx.xx.xx connect,resolve)
}

int len = con.getContentLength(); // this throws AccessControlException: access denied (SocketPermission xx.xx.xx.xx connect,resolve)
if(len == -1)
{
   // http 1.1 chunked
}
else
{
  // http normal
}
#5

Bugger…

I have 2 systems, both are identical: FireFox 2.0.0.14 Java Plug-in 1.6.0_05 Using JRE version 1.6.0_05 Java HotSpot(TM) Client VM

One works, one doesn’t.

Write once, run anywhere, with varying results

#6

Are you using LiveConnect? It sounds like it might be this bug:
http://bugs.sun.com/view_bug.do?bug_id=6669818
The bug existed 1.6.0_03, fixed in 6u10

#7

Thanks for replying!

Although I’m not using LiveConnect, I found this on the bug-page you gave me:
-> http://forum.java.sun.com/thread.jspa?threadID=5230759&start=30
—> http://oueb.org/AppletFireFoxLiveconnectBug.html
-----> http://oueb.org/AppletFireFoxLiveconnectBug.java

There, the button within the applet successfully reads from an URLConnection in Firefox (yay!)

So I guess I’ll be playing around with the provided sourcecode and see what’s the diff (if any…)

#8

So… it works now, but it does not make sense.

I simply put the given example code in Applet.start()


   public void start()
   {
      try
      {
         URL url = new URL( "http://www.abcdef.com/" );
         URLConnection conn = url.openConnection();
         conn.setDoOutput( false );
         BufferedReader br = new BufferedReader( new InputStreamReader( conn.getInputStream() ) );
         String line;
         StringBuffer response = new StringBuffer();
         while( (line = br.readLine()) != null )
            response.append( line );
         br.close();
      }
      catch (Exception exc)
      {
         exc.printStackTrace();
      }
   }

After that, all my further URLConnections work…!

And if I remove that (useless) code in Applet.start(), it breaks down instantly.

Seems to me like some threading-issue. Appearantly you have to be in the thread that calls applet.start() to do the first URLConnection, after that it doesn’t matter which Thread does the I/O… ::slight_smile:

#9

I’ve just started to see exactly the same problem. I’ve got an applet (Pipe Extreme, http://games.7sun.com/applet.php?game=50) which loads some resources from the host after the applet has started. It has worked fine for ages. Now though, it works OK the first time firefox loads it. But if I then clear the applet cache (x in console) and hit ctrl-F5 in firefox… the resources fail to load… arrrrgggh!!

Clear classloader cache … completed.
java.security.AccessControlException: access denied (java.net.SocketPermission 65.254.51.202:80 connect,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 java.net.Socket.connect(Unknown Source)
etc…

I noticed it as I’m doing some development at the moment to add an online highscore facility, so I’m testing the applet a lot in firefox. Bizarrely it seems to me to have only broken recently… Is it perhaps due to firefox updating to 2.0.0.14?

Or maybe its the java runtime… I’ve tried jre versions 1.6.0_03 and 1.6.0_05?

BTW, Riven, your workaround above doesn’t work for me.

Cheers, Tim.

#10

Does this one work:
http://oueb.org/AppletFireFoxLiveconnectBug.html

click the button IN the applet, that one works for me… which is enough, as I don 't care about LiveConnect

It still works after I press ‘x’ in the JavaConsole

#11

… did you try Ctrl-F5 before clicking the java button again?

The sequence below replicates what I’m seeing in my applet:
Click Java button. – This works fine.
Click JavaScript button. – This produces an ACE, as expected.
‘x’ in Java console window.
Ctrl-F5 in Firefox to reload page.
Click Java button. – This now produces an ACE. Close and restart Firefox completely to get it to work again.

That this started happening with my applet late yesterday afternoon is a complete mystery to me, as I had been doing the ‘x’, Ctrl-F5 sequence all weekend to reload my applet, and it worked fine (loading resources and high scores from the server). Just as I got it to the state where I was doing final testing to release it, it started to fail every time (due to this bug of course). What a pain. :slight_smile:

I think I’m going to have to start using IE to develop with until this bug is fixed. doh!

Cheers, Tim.

#12

Yes, it throws an ACE with that exact sequence.

But without that LiveConnect button, it works, even with ‘x’ and CTRL+F5

#13

True. Up till now I’ve been using LiveConnect in my applet to save the “local” high scores (via a cookie). This is the only LiveConnect code used. I guess that once I’ve finally got server side high scores working I could just remove the local ones. It’s a shame though, as I’d like to keep them.

I don’t suppose anyone knows some way, other than using LiveConnect with Cookies, of persisting data from an unsigned applet?

Cheers, Tim.

#14

Applet => website


   public void executeScript(String js)
   {
         try
         {
            String path = "javascript:eval(hexToStr('" + strToHex(js) + "'));";
            this.getAppletContext().showDocument(new URL(path), "_self");
         }
         catch (Exception exc)
         {
            // probably Opera
         }
   }

Website => Applet

  • Website: write into Applet using Javascript / DOM
  • Applet: polling applet.getParameter(“myProperty”) every N ms
#15

Just to clearify, you need to ‘encode’ and ‘decode’ the javascript you want to execute in the browser because is won’t probably be a valid URL.

Here is some incredibly ineffictient (who cares) javascript for strToHex() and hexToStr()



function strToHex(str)
{
	var hex = "";
	for(var i=0; i<str.length; i++)
		hex += itoh(str.charCodeAt(i));	
	return hex;
}

function hexToStr(hex)
{
	var str = "";
	for(var i=0; i<hex.length; i+=2)
		str += String.fromCharCode(htoi(hex.substring(i, i+2)));
	return str;
}

function itoh_(i)
{
	return "0123456789ABCDEF".charAt(i);	
}

function itoh(i)
{
	var hi = (i >> 4) & 15;
	var lo = (i >> 0) & 15;
	return itoh_(hi)+""+itoh_(lo);
}

function htoi_(h)
{
	return "0123456789ABCDEF".indexOf(h);
}

function htoi(h)
{
	var hi = (htoi_(h.charAt(0)) & 15) << 4;
	var lo = (htoi_(h.charAt(1)) & 15) << 0;
	return hi+lo;
}

Java versions:


   private static char[] hexTable = "0123456789ABCDEF".toCharArray();

   public static final String strToHex(String str)
   {
      try
      {
         return rawToHex(str.getBytes("utf8"));
      }
      catch(UnsupportedEncodingException exc)
      {
         return null;
      }
   }

   public static final String hexToStr(String hex)
   {
      try
      {
         return new String(hexToRaw(hex), "utf8");
      }
      catch(UnsupportedEncodingException exc)
      {
         return null;
      }
   }

   public static final String rawToHex(byte[] raw)
   {
      char[] digits = new char[raw.length * 2];
      for (int k = 0; k < raw.length; k++)
         for (int i = 0; i < 2; i++)
            digits[(k << 1) + (1 - i)] = hexTable[(hex[k] >>> (i << 2)) & 0x0F];
      return new String(digits);
   }

   public static final byte[] hexToRaw(String hex)
   {
      byte[] raw = new byte[hex.length() / 2];
      for (int i = 0; i < raw.length; i++)
      {
         char c0 = hex.charAt((i << 1) + 0);
         char c1 = hex.charAt((i << 1) + 1);

         int val = (c0 - (c0 < 'A' ? '0' : 'A')) << 4;
         raw[i] = (byte) (val | (c1 - (c1 < 'A' ? '0' : 'A')));
      }
      return raw;
   }
#16
  • see previous page
#17

That’s just great, thanks Riven. I’ll give it a try tonight.

Cheers, Tim.

#18

Keep in mind I ‘manually wrote’ (…) that code in the reply (not a copy/paste).

I don’t have the sourcecode here right now, only the bytecode :slight_smile:

The concept works though.

#19

cool, excellent that you find a workaround to this FF bug , great!

#20

I did finally get around to trying this… and it does run the javascript code as advertised.

However, it also changes the document :slight_smile: Is there some trick to getting the browser to run the javascript, but not change the document? Or should the javascript just change the document back again… but then I guess the applet would re-start? Or maybe I need to run it in a (non-visible) frame (but I’d prefer not to use frames at all)?

Hmmm, tricky.

Cheers, Tim.