[5250] in java-interest
Re: Netscape security => lame applets
daemon@ATHENA.MIT.EDU (Doug Lea)
Sat Feb 3 11:20:01 1996
Date: Sat, 3 Feb 1996 09:36:29 -0500
From: Doug Lea <dl@altair.cs.oswego.edu>
To: horstman@jupiter.SJSU.EDU
CC: darcy@arcs.bcit.bc.ca, java-interest@java.sun.com
In-reply-to: <01BAF192.CC6E2640@Cay Horstmann.SJSU.EDU> (message from Cay
Horstmann on Fri, 2 Feb 1996 17:20:43 -0800)
Cay writes...
> Let's hope someone rewrites that page to be a little clearer about what
> would be involved in writing such an applet.
>
Well, I'm not allowed to rewrite the page :-) but I know of at least
one way to arrange for an Applet to communicate with an arbitrary
number of servers, so long as they are set up to allow this. (I'm not
sure that this method is to be encouraged, or even if it falls under
the intent of current Applet security policies, but it seems to work.)
The rules state that an applet can only communicate with the machine
that it was loaded from (as specified in the `codebase' of the applet
tag of the html document that launched it). So in order to communicate
with a lot of machines, you need to load a lot of Applets. One way to
do this is to write an html page loading an Applet (of a special form)
from every server that some main applet will need to communicate with.
Each of these Applets can support a public method that tries to open a
connection itself if it is to the same machine as it was loaded from,
but if not, to hunt around for (via getAppletContext().getApplets()) a
co-resident Applet that can. For example, all could be subclasses of:
import java.applet.*;
import java.util.*;
import java.net.*;
import java.io.*;
public class ConnectingApplet extends Applet {
/* Skeletal but functional example code: */
public URLConnection openURL(URL u) throws IOException {
if (u.getHost().equals(getCodeBase().getHost()))
return u.openConnection();
for (Enumeration e = getAppletContext().getApplets(); e.hasMoreElements();) {
Applet a = (Applet)(e.nextElement());
if (a instanceof ConnectingApplet) {
if (u.getHost().equals(a.getCodeBase().getHost()))
return ((ConnectingApplet)(a)).openURL(u);
}
}
/*
Note: At least in netscape-2b6, if the above Enumeration loop
runs before an Applet has been fully loaded, it will fail to
list it. To live with this, if you know one will be coming, you could
just keep re-trying until it becomes loaded, or eventually
time out and take evasive action. To help manage such things,
instead of relying on AppletContext, you could build
your own registry; for example like the one sketched out in
the tutorial in http://g.oswego.edu/dl/pats/aopintro.html
*/
return null; // or otherwise somehow fail
}
/*
Similarly, you could support
public Socket openSocket(String hostname, int port);
and so on.
*/
}
Each distinct applet has to be an instance of distinct subclass of
ConnectingApplet, to ensure that it is loaded from its codebase. All
but the main Applet might as well have an empty start() method; in
fact just:
public class ConnectingAppletAtServer1DotFooDotEdu extends ConnectingApplet {}
And occupy no screen space:
<applet
codebase="http://server1.foo.edu/classes"
code="ConnectingAppletAtServer1DotFooDotEdu"
height=0 width=0
>
</applet>
You could probably find a way to use JavaScript to dynamically
configure a set of helper connection applets needed by the main
applet. (I haven't tried this.) Or perhaps source the page from a CGI
that did this kind of configuration.
For example, if you standardized things so that every `friendly'
server S that you ever needed to deal with was guaranteed to have a
class `ConnectingAppletAtFullHostNameOfS', you could blindly generate
an html <applet> of the right form for each one you need.
In this case, the basic connection policy amounts to:
If a server S would like to be talked to by an arbitrary Applet, then
it must possess a ConnectingAppletAtFullHostNameOfS.class file in
a known location.
This is just a more structured variant of the current Applet rules,
adapted to a kind of `advertised service' design. (It is also fully
secure, at least in the sense that a server is accessible in this
fashion ONLY if it possesses such a class. Of course, if you like,
you can add additional protocols on top of this. For example,
requiring that accessible servers use https (secure http) and/or
handcrafting some other kind of authentication policy.)
Since distributed OO applications tend to be structured more along the
lines of peer-to-peer (internet style) architectures rather than
traditional stateless-client/bulky-server architectures (that the
current Applet rules most readily support), you'd probably end up
placing these classes on every single node of any large scale WWW
application. Among other things, this allows each node to maintain and
access its own state without swamping servers that would otherwise
have to manage state on behalf of each client, which doesn't scale
very well in many applications.
This all has the limitation that Applets cannot connect to new
machines that they learn about in the course of computation. This and
other problems could be addressed by adding a level of indirection,
and putting up CGIs on each friendly server that will dynamically
maintain and route requests to other known friendly servers if they
don't directly connect to the requested URL. And from there, you could
add routing metrics, nameservers, monitors, security protocols, ...
In the extreme, you could arrange things so that you need only load a
single RouterApplet along with each main Applet, and let the Router
handle all connections. Although having lots of them helps avoid
single-point failure and congestion problems.
I shudder to think of the large-scale consequences of such designs
though. It amounts to setting up a second-level internet routing
structure on top of the already existing base internet routing
structure. Ad-hoc Java versions like the above are unlikely (at
best!) to be as efficient, well-tested, well-structured, or
well-managed as the underlying ones. It would be nicer if Applet rules
were changed to allow Applets just to use underlying capabilities
under some tolerable set of security policies.
--
Doug Lea | dl@cs.oswego.edu | dl@cat.syr.edu | 315-341-2688 | FAX 315-341-5424
Computer Science Dept, SUNY Oswego, Oswego, NY 13126 | http://g.oswego.edu/dl/
Also: Software Eng. Lab, NY CASE Center, Syracuse Univ, Syracuse NY 13244
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
