[Json-rpc-java] Callable references and Constructors

[Arthur Blake]

Here are my thoughts:

First of all, I think this would only really be a desirable feature when one
is using References and/or Callable References-- so if it is added, I'd like
for a way to turn it off (and preferably have it and callable references,
off, by default.)

How many people use References/CallableReferences? (I never have.)
Obviously you do use them quite a lot, and I'm sure they come in really
handy.  I haven't had a need to use that feature, yet.

In the simple case where one is not using Refs/Callable Refs (and objects
are passed by value), to have server side support for constructors is quite
literally, a waste of time.  Not a waste of time from a convenience or
intellectual point of view, mind you, but a serious waste of bandwidth and
server CPU resources, because it's completely unnecessary.

You can do it all on the JavaScript side, which will be an order of
magnitude faster (given that it doesn't involve a network round trip,
serialize / deserialize, etc.).
A simple example is just doing:

var x = {javaClass:"mypackage.MyClass", someParm: someValue, etc:etc};

Now the variable x, holds a newly constructed object that can be passed back
to the java side, and it will be "newed" up as a java side object as soon as
it hits the server.

I often create a javascript side "class" for doing this sort of thing.
e.g.
function MyClass(myparm)
{
  this.javaClass="mypackage.MyClass";
  this.someParm = myparm;
};

then the javascript side notation is even more "java-like";

x=new MyClass(myparm);


Secondly, I would think that you would really need to be a LOT more careful
about security if you add the ability to construct objects from a client.
The BeanSerializer is already somewhat insecure and wide-open in that it can
already construct any class type that has a no-arg constructor, passed to
it, on the fly -- but having the ability to actually pass arguments to a
constructor without some additional security precautions being added into
the framework is a recipe for disaster.  I can imagine someone hacking into
your system and newing up a File object that points to some sensitive
information and then reading it, and or deleting it.

The security aspect is something on the TODO list already, and the security
issue already exists in somewhat milder form (possibly benign-- I'm not
completely sure about this one), but if you open up any constructor on any
class type, then the security issue will be critical.

So, I suppose in conclusion, this would be a nice feature to have-- but only
for constructing references that are promptly added to the Session on the
server, and with a comprehensive security framework in place.

Speaking of security in json-rpc-java (I guess this is as good a time as any
to segway into some of my ideas on that) the proposed solution on the TODO
list, is:

"Make BeanSerializer require that Bean objects implement Serializer before
it will marshall or unmarshall them (to add an additional layer of
security)."

I think this is a good idea, but I think the security model should be more
flexible.  I think a JSONRpcBridge object should allow any number of
"SecurityPolicy" objects to be registered with it, just like server side
call Objects are registered with it.  SecurityPolicy would be an interface
that sits in front of the JSONSerializer and/or method call, so it can
intervene in any way it wants to by throwing some sort of
SecurityPolicyException.  (this is a bit similar to the registerCallback
method in the bridge that can register an object that gets called before any
method is invoked, except that the SecurityPolicy object also be called at
serialization/deserialization time to enforce some kind of security policy.)

Several standard implementations could be provided, one that requires all
objects being serialized/deserialized to implement Serializer (as in the
TODO list.)
One that just contains a Map of allowed and/or disallowed classes, to lock
down exactly which types of classes can be serialized/deserialized.
One that can match by regular expression and/or package name.

This also allows a user to implement and register their own SecurityPolicy
object, for ultimate flexibility, and multiple SecurityPolicy's could be
registered to have more complex sets of allowed/disallowed objects during
serialization. (I'm imaging the way file set excludes/excludes work in ant)

Now, a JSONRpcBridge could also have some sort of default security policy
that takes effect if no SecurityPolicy implementations are registered on the
Bridge (perhaps just doing what the TODO list says, after all!)

So- I look forward to your response and anyone else's thoughts on the
matter.

Arthur

(P.S. I'm still going to get back to the list about the Circular References
issue- I just haven't had time to review William's code yet.  But I think
there is definitely room for a solution that everyone would be happy
with...)


On 8/10/07, William Becker <wbecker at gmail.com> wrote:
>
> Hi,
>
> I am using JSON-RPC a bit at the moment, especially with callable
> references
> and it all seems to be working quite well. It's got to the stage however
> where not only do I want to use objects that I have got from the server,
> but
> I wouldn't mind being able to create them as well. I'm sure I could write
> a
> function on the server side that just gets an empty Class and then
> populate
> it with set()s but I'd rather use a constructor. Is this implemented? It
> doesn't seem to be a TODO so either people haven't thought of this,
> thought
> it was just silly or even better it's done and nobody is touting its
> advantages. I'm guessing its either the first or the second though.
>
> I think I should be able to write it up in that case. I imagine the JSON
> would look like:
>
> {"id":25,"method":"constructor","className":"java.lang.Object or just
> plain
> Object","params":["_2"]}
>
> instead of a normal function call that looks something like:
>
> {"id":25,"method":".obj_404837374.getValue","params":[arg1,arg2]}
>
> Does any one have any thoughts about this?
>
> Cheers,
> Will
> _______________________________________________
> Json-rpc-java mailing list
> Json-rpc-java at oss.metaparadigm.com
> http://oss.metaparadigm.com/mailman/listinfo/json-rpc-java
>