Sure, one wrapper and it's called NativeJavaObject, right? Seriously, I actually considered the idea of writing a wrapper class for this purpose and I came up with two ideas: 1) Take the guts of NativeJavaObject, JavaMembers and all supporting classes and make them do what I wanted them to do. 2) Or, write a wrapper which extends the NativeJavaObject created by Rhino. Implement get, set, getIds in order to "hide" the functions I don't want to expose. The first option is bad because unless done correctly would violate terms of the copyright. The second, though works, is rather inefficient because it adds overhead to every propery/function operation on every wrapped java object. I thought that since I have this problem, perhaps other embedders of Rhino would too and why not make a solution which could be used (optionally) by others. Kevin
________________________________ From: [EMAIL PROTECTED] on behalf of Charles Lowell Sent: Sat 11/29/2008 9:23 AM To: [email protected] Subject: Re: Enhancement to ClassShutter to control member function visibility 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 _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
