Secure Class Loading

[Michael Garvie]

Hello everyone,

I have a client - server app where the client is always online and gets
sent objects of type, say, Fruit from the server. However now and again
the server goes down and Fruit gets recompiled for bug fixes etc.

Is there a way of making the client forget all the classes it has seen
so far and load everything again when it sees the next Fruit object?
Some people have suggested using something like URLClassLoader but this
has two problems:
1) Now we must create an instance of the class using no constructor..
So the server isn't really defining what object it sends to the clients
anymore, they read it from a static source.
2) Unsecure, the client must be granted createClassLoader
RuntimePermission which is very unsecure.

Does anyone know a way round this?

Cheers,
Miguel

 

[dhek bhun kho]

Hello everyone,

I have a client - server app where the client is always online and gets
sent objects of type, say, Fruit from the server. However now and again
the server goes down and Fruit gets recompiled for bug fixes etc.

Is there a way of making the client forget all the classes it has seen
so far and load everything again when it sees the next Fruit object?
Some people have suggested using something like URLClassLoader but this
has two problems:
1) Now we must create an instance of the class using no constructor..
So the server isn't really defining what object it sends to the clients
anymore, they read it from a static source.

Are you sure about this? I do not know what your security policy is, but
there is no requirement that you can only use the default constructor.

I.e. (just a hint, this code does not work, but the sequence of method
calls are correct)

ClassLoader cl = ...;
Class dynamicClass = cl.loadClass("classname");
Class[] arguments = new Class[] {String.class};
Object[] arguments = new Object[] {"argument"};
Constructor constructor = dynamicClass.getConstructor(arguments);
Object newObject = constructor.newInstance(arguments);

So point (1) does not stand.

2) Unsecure, the client must be granted createClassLoader
RuntimePermission which is very unsecure.

I'm not sure about this, but I thought that an applet context do not have
this permission. And by all means the applet security policy is very
restrictive. But you can still instantiate a new copy of the current
class loader like this (assuming it is an URLClassLoader, which is the one
you should be working with anyway):

<code>
// again, this code is non-functional.
URL[] urls = new URL[] { new URL(..) , ..., new URL(...) }; // classpath
((URLClassLoader)getClass().getClassLoader()).newInstance(urls);

Does anyone know a way round this?

Try the above. It's hard to tell from here.