Unsigned applet and TCP 'host' connexion restriction

Hi,

I’m working on a online gaming website based on the (excellent) pulpcore framework and so, unsigned applet.
The game itself uses a TCP connexion to my dedicated server. For the moment, both web server (from where applet is downloaded) and ‘TCP game server’ are hosted on the same machine. So I don’t face any SecurityException.

But I’ll need soon to separate the web server from the game server.
Thus, I would like to understand how Java restricts TCP connexion from untrusted applets: are restrictions based on the DNS hostname or the IP ?

For example, say I have:

  • one web server (www.mysite.com) where the applet is downloaded. It has IP 80.169.0.1
  • another server with a different IP (80.169.0.2) and another domain name, but with the same ‘second level domain’ name (mysite.com), say ‘tcpserver.mysite.com

=> will a TCP connexion in my applet be able to connect to ‘tcpserver.mysite.com’ even if the applet itself has been downloaded from ‘www.mysite.com’ ?

=> If not, is there any way to make a unsigned applet connect to a server with a different IP, but on the same domain ?

Many thanks in advance.

Easiest solution: write a tiny application that listens on port N, and sends everything it receives to ‘host 2’. Everything it receives from ‘host 2’ will be sent to the applet again, over the same TCP connection. The only downside is that you have twice the traffic, but usually that’s not your bottleneck.

I believe the restriction is by IP address. If you provide a host name, java does a DNS lookup.

There is some new cross-site functionality in Java 6. Might work, although I saw some posts in sun forums, which suggested that it worked with URL Connections but not raw sockets. If this is true, it might not help you

https://jdk6.dev.java.net/plugin2/#CROSSDOMAINXML

I was interested myself, and found a demo here
http://weblogs.java.net/blog/joshy/archive/2008/05/java_doodle_cro.html

There’s some source code in a .zip further down the page. It appears to do an imageio.read(URL)

The crossdomain support appears to be in CheckConnect

It seems to be regularly fixed and broken in each release so probably not ready for production use yet.

http://forums.java.net/jive/thread.jspa?messageID=331872

[quote=“nouknouk,post:1,topic:34927”]
A workaround would be to have two applets on the page; the game applet <codebase=www.mysite.com> and a 1x1 pixel comms applet <codebase=tcpserver.mysite.com>.
Because applets can talk to eachother, the comms applet can act as a bridge between the game and the server. Might be a bit slow…

Have you tried this?? AFAIK the security manager checks the host of the webpage, not the codebase of the applet.

Er, no. Not as such - I have run 2 applets from totally different codebases on the same page, but I haven’t tried server comms with them. I assumed that if you can run an applet from a codebase then that applet can talk to that codebase? You think maybe not…?

Edit: just did a quick test and it does seem to work - maybe not all security managers are the same? :-\

Hi,

first thanks for your replies.

I finally bought a domain to perform some tests.
Here is my precise testing configuration:

  • one physical server with one (public) IP: IP1

  • antoher physical server with two network cards and two (public) IPs: IP2 and IP3

  • one domain name (mydomain.com), with:

Here are the first results:

-> with no security restriction (applet ran locally), any host:port connexion succeeded.

-> with unsigned applet embedded (ie. sandbox active) in a web page of subdomain.mydomain.com, i get:

So it seems the security check is well based on the IP resolved by the DNS request, which is a problem for me.

I think I’ll try some tests with one applet and a different CODEBASE parameter, as proposed by SimonH. But my problem is that I use the ‘archive’ tag to define the applet’s JAR location ; I suppose both won’t be allowed, and (maybe) if I define a codebase with a different URL than the one where the JAR is located, the applet will throw a NoClassDefFound error because it won’t find the applet’s jar. don’t you think ?

About having two applets in the same webpage: it’s not really a solution for me, as:

  • I did some tests a long time ago, and as far as I remember, compability with all browsers + all JRE (1.4+) was not guaranteed.

  • I have constraints regarding network latency (think ‘action game network requirements’). And I suppose that inter-applet communication will likely be a problem for that.

About cross-site functionality, it’s not a solution for me too, as my applets must be compatible with any JRE 1.4+

Note1: when connexion failed, the exception looks like “(java.security.AccessControlException: access denied (java.net.SocketPermission otherserver1.mydomain.com resolve))”

Note2: the code of the applet itself looks like:


public class TestAppletSecurity extends Applet {
    @Override
    public void init() {
        System.out.println("TestAppletSecurity initialization.");
        testTcpConnexion("mydomain.com", 80);
        testTcpConnexion("subdomain.mydomain.com", 80);
        testTcpConnexion("otherserver1.mydomain.com", 80);
        testTcpConnexion("otherserver2.mydomain.com", 80);
        testTcpConnexion("serverid.myprovider.com", 80);
    }
    public void testTcpConnexion(String host, int port) {
        try {
            Socket s = new Socket(host, port);
            s.close();
            System.out.println(" -> '"+host+":"+port+" : connexion SUCCEEDED.");
        } catch (Exception e) {
            System.out.println(" -> '"+host+":"+port+" : connexion FAILED ("+e+")");
        }
    }

Seriously, do this:

Hi,

I already thought about such solution, but it leads to four issues:

1- as you said, the use of the bandwidth is not efficient at all. And it will quickly become a problem as my bandwidth is not unlimited.

2- it will raise latency, and this won’t be a good thing for my ‘real time’ requirements.

3- it will have an impact of the server1’s load (the one which runs the ‘proxy’ daemon), which is the thing I want to avoid (separation of web server and ‘game server’ is mostly intended to support load).

4- one option I was planning was to rent one dedicated server (for ‘game server’) and only one ‘web hosting’ place (usually cheaper). But if I need a proxy software on the same IP than the web server, this no more an option.

  1. factor 2 isn’t that bad. you can reduce traffic much more by having efficient networkcode
  2. an additional latency of under 1-2ms, which is negligable, as the location of the user can cause latencies of hundreds of millis.
  3. you can handle hundreds of connections, with a linux-load near 0.01, when using NIO, if all the application does is redirecting traffic
  4. Why? The proxy would run on the same IP, but a different port (not 80). A cheap VPS is all you need.

riven, the topic is not about finding a workaround (which will in any case restict my possibilities), but more having a precise and complete overview about what can be done (or not) with unsigned applets. Having the information is the first step. Given it, I’ll decide on my own what is the best solution for my specific case.

So it’s off topic, but just for information:

  1. factor 2 is simply huge and my network protocol is already efficient.
  2. additional latency of 1-2ms is only if the two servers are hosted in the same place. Such case forbids me to rent two separate servers in two different companies.
  3. good to know.
  4. the solution was about renting only two servers: one for hosting only (so no ‘root’ access and no way to execute the proxy) and another one for ‘game server’ only (dedicated server).

At the risk of completely annoying you, let me add that you can solve #4 by putting the proxy on your dedicated server and actually tunnel traffic to your website.

Feel free to ignore :slight_smile:

so where is the problem ? just serve the applet (maybe in an IFrame if you want it merged with some of your website page) from the game server and not from the “hosting” one ?

<HTML>
<HEAD>
<TITLE> page served by http://website.com/</TITLE>
</HEAD>
<BODY>
<IFRAME src="http://game.website.com/applet.html?+someParametersFromWebSite"></IFRAME>
</BODY>
</HTML>

EDIT: also not sure that you can connect to other port then the one that serve the applet with all JRE

AGAIN, the subject of the topic is to understand to what an unsigned applet can connect (or not), not finding a workaround.

And about your off-topic: let’s try to make two applet communicate to each other in two different IFrames. Same question about liveConnect feature (ie. Javascript <=> java calls). There are even other issues with use of IFrames.

so the answer is no no no… Unsigned Applet does not allow to connect to another server without a workaround (proxy) than the one that the applet come from… end of the debate

[quote]=> If not, is there any way to make a unsigned applet connect to a server with a different IP, but on the same domain ?
[/quote]
hey man ! you ask for a workaround, you are offtopic !

heu why would you like to comunicate client side between two applet comming frm a different server ?

That’s it:

[quote=“DzzD,post:15,topic:34927”]
It was a pleasure, gentlemens.

Please keep in mind we are trying to help you.