On Nov 26, 10:56 am, "Ruland Kevin-BHP637" <[EMAIL PROTECTED]> wrote: > Hi all, > > I created an enhancement > bughttp://bugzilla.mozilla.org/show_bug.cgi?id=466509and 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. >
Apologies if someone suggested this already, but I believe you would only need to write a single wrapper which could be applied to all java objects serviced by your WrapFactory. As for the wrapper itself, extending NativeJavaObject would get you most of the way there... > 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 [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
