Hi all,
I created an enhancement bug
http://bugzilla.mozilla.org/show_bug.cgi?id=466509 and attached a
proposed patch to implement the functionality. Essentially, I am
looking for an easy way to provide access to native Java objects but
prevent scripts from accessing "dangerous" member functions - in
particular Object.wait.
One previous post suggested I create a derived Java Object for this.
There are two problems with this solution. First, Java prevents
reducing visibility overridden in the derived class. Second, Java
prevents overriding final members such as Object.wait.
Another alternative would be to build JS wrapper objects implementing
the Scriptable interface and only providing access to "safe" members.
This represents considerable effort because every "useful" Java class
would need such a wrapper to eliminate Object.wait.
It seemed the best alternative was to provide the developer of the
embedding determine through some manner which members should be excluded
in the NativeJavaObject wrapped object.
I extended the ClassShutter interface to define a second method
visibleToScripts( Method method ) which is called during the JavaMembers
discovery process. A member function is added to the mapping only if
the Context has a ClassShutter and visibleToScripts returns true. This
essentially leaves it to the developer to define an algorithm which
allows or disallows member functions in a arbitrary fashon.
It could be possible for a default ClassShutter derived class be defined
in the Context which handles the FEATURE_ENHANCED_JAVA_ACCESS flag which
could further simplify the discovery process.
Changing the ClassShutter interface may not be desirable because it does
represent an API change and any application which uses an implementation
of ClassShutter would have to change. I feel this is a minimal
inconvience to developers but does require recompilation of some
applications. There are two ways to mitigate this problem: 1) Define
an extention interface, interface MemberShutter extends ClassShutter,
then use "instanceof" in the JavaMembers to determine if the
ClassShutter in the Context is the appropriate type. 2) Define a
default implementation base class which simply returns true for both
defined methods. Applicaiton developers could then extend this base
class instead of implementing the interface directly. This still
requires a recompile but applications using this approach could be
isolated from further changes to the ClassShutter interface.
Finally, there are potentially some edge cases which I have not
explored. For example, I don't understand the interaction with overload
resolution. Here's a concrete example, Suppose you define a
ClassShutter which prevents access to Object.wait(long) but allows
access to Object.wait(). I don't know if from JavaScript, the one
argument form could still be called. (I suspect you can call it.)
Please look at this patch and let me know if its on the right track or
completely off base.
Thanks
Kevin
_______________________________________________
dev-tech-js-engine-rhino mailing list
dev-tech-js-engine-rhino@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
