Google appengine + applet AccessControlException

[ShannonSmith]

I am having a problem getting my applet to connect back to a google appengine servlet. The HttpURLConnection always fails with:
java.security.AccessControlException: access denied (java.net.SocketPermission 72.14.213.141 resolve)

I have tried a bunch of stuff to get it working (can't even connect to the applet getCodebase() URL) and I'm out of ideas. One thing that is interesting is the exception has an IP address in it rather than the host name, is google doing some funny redirect that is confusing the applet or have I done something stupid?

[Riven]

Start with plain socket access:

1	new Socket(Applet.getDocumentBase().getHost(), 80);

and check whether that works.

[ShannonSmith]

Nope that doesn't work either.

Games published by our own members! Check 'em out!

[SimonH]

You have to use URLConnections; (NB fragmentary code only - omitted error trapping &c for clarity)

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18

String data="Hello Servlet!"; url = new URL(codeBase+appName); urlConnection = url.openConnection(); // inform servlet that this is a service request urlConnection.setRequestProperty("Content-Type", "application/service"); urlConnection.setDoInput(true); urlConnection.setDoOutput(true); // disable caching urlConnection.setDefaultUseCaches(false); urlConnection.setUseCaches(false); outputStream = urlConnection.getOutputStream(); outputStream.write(data.getBytes()); outputStream.flush(); outputStream.close(); // get response inputStream = urlConnection.getInputStream(); &c.

[ShannonSmith]

Why would a URLConnection work and an HttpURLConnection not work?

[Riven]

There is nothing magical about URLConnection. It creates a Socket under the hood.

[Riven]

So the security manager complains about: "72.14.213.141"

Could you check the hostname in the addressbar of your browser and see what it IP it resolves to? (ping it). Please make sure you use exactly the same (sub)domain.

[ShannonSmith]

Yeah, that is what I don't get. The URL is constructed with a hostname / path and the security manager is complaining about an IP address. Google uses load balancing so I assume each request could go to a different IP address.

Visiting again I get error with :
74.125.127.141
Pinging the hostname gives me the same IP.

How does the applet sandbox check addresses?

[Riven]

The sandbox is pretty silly actually. It checks the IP address only. It grabs the IP from the browser, through the plugin, and compares any domainname/IP you try to connect to, to that IP. If it's not the same IP, an exception is thrown.

[Orangy Tang]

Yeah, that is what I don't get. The URL is constructed with a hostname / path and the security manager is complaining about an IP address. Google uses load balancing so I assume each request could go to a different IP address.

The should go to the same load-balancing machine first though, even if that routes it to a different box on the backend.

Are you connecting back to the *exact* same host, or is it a subdomain? I know that in theory the sandbox should allow applets served from "host.com" to connect to subdomains "appengine.host.com", but in practice the security manager doesn't like that.  

Games published by our own members! Check 'em out!

[Riven]

I know that in theory the sandbox should allow applets served from "host.com" to connect to subdomains "appengine.host.com", but in practice the security manager doesn't like that.  

Actually, the rules are quite clear: it's all IP based. If the subdomain has the same IP as the domain, you can connect to it.

[ShannonSmith]

I am using a subdomain of appspot.com (the google appengine host) and if I ping the mysubdomain.appspot.com I get the same IP address as it is complaining about in the AccessControlException. What gives?

Why would

1	new Socket(Applet.getDocumentBase().getHost(), 80);

ever fail?

[Riven]

1   2   3   4   5   6

String host=Applet.getDocumentBase().getHost(); System.out.println(host); InetAddress addr=InetAddress.getByName(host); System.out.println(addr); System.out.println(addr.getHostAddress());

What is printed?

[ShannonSmith]

synthpatches.appspot.com
synthpatches.appspot.com/74.125.127.141
74.125.127.141
java.security.AccessControlException: access denied (java.net.SocketPermission 74.125.127.141:80 connect,resolve)

Any ideas?

[Riven]

Are the JAR files hosted on the same IP?

1	MyApplet.this.getClass().getProtectionDomain().getCodeSource().getLocation();

[ShannonSmith]

The jar is located at the same IP.

Can't getProtectionDomain() from applet sandbox.
java.security.AccessControlException: access denied (java.lang.RuntimePermission getProtectionDomain)
   

[Riven]

Please read this thread and try to see whether that works:
http://www.java-gaming.org/topics/applet-can-t-connect-to-own-host-in-firefox/18652/view.html

Especially:
http://www.java-gaming.org/topics/applet-can-t-connect-to-own-host-in-firefox/18652/msg/146559/view.html#msg146559

[ShannonSmith]

Yay, got it working! Just not quite sure how. Did about a million things (including operating system upgrade) cleaned every cache I could find, re-deployed everything and all of a sudden it works. It would be really nice if those AccessControlExceptions were a bit more specific (telling me the IP it is expecting to match for example).

Thanks for you help Riven.

[Riven]

Please *also* apply my suggested nonsense-fix in that thread.

There will be a lot more people with that ACE in *your* applet, if you don't.

[ShannonSmith]

Will do, I did make a few other changes to the applet that may have fixed this because of that issue. I moved some code from the Applet constructor into init() and also changed the URL constructor to use the 3-argument protocol,server,file. The applet/server networking seems very brittle and is a nightmare to debug also there is precious little documentation about it on the web.

 

[Riven]

Have you considered signing your JARs? It will cause a security-popup, but it's a lot more stable (across JRE versions).

[ShannonSmith]

Signing makes things a lot easier but I think the number of people turned away by scary security dialog would be higher than the number of people who have issues running the unsigned version because of sandbox problems (assuming lots of testing on several different computers/operating systems).