Hi Jasvir, Thank you very much for the very helpful ways to care about the security concerns. Please see my comments in blue below.
Best Regards, Kevin, Zhang Kai Feng IBM Project Vulcan Development IBM China Software Development Lab 2010/11/3 ๏̯͡๏ Jasvir Nagra <[email protected]> > Sorry that was perhaps less than helpful. I looked over the thread you > referenced and I think a few clarifications are needed. I realized there > is > a mis-interpretation that Caja is primarily aimed at "addressing malware > and > security concerns". The point is that the accidental problems that you > mention above _are_ the security concerns Caja is concerned with - when > they > occur in trusted code, they cause the functionality to break. We simply > happen to treat both this unintended incorrectness in trusted code along > with deliberate attack by untrusted code as different instances of the same > class of problem - that of isolation. > We did try Caja, but there are some some flaws that we can not make use of it, please see my above long note. > > If you are willing to ignore the javascript problem - which is the source > of > most of the complexity - you be mostly able to isolate html and css by: > > * rewriting all ids with a instance-based prefix > * creating a new div with an class id that has an instance-based prefix > * clipping to this div (this prevents a gadget from accidentally using > absolute positioning) > * rewriting all classes in the gadget to be scope to that instance-based > prefix > > If you are not rewriting javascript, the problem then becomes one of asking > that gadget developers use your apis to get and set html elements in the > gadget (including when setting innerHTML) so that they actually get the > right elements and don't accidentally clobber another gadget instance that > has been inlined. > I think our target is to make inline gadgets behave same as iframe gadget(at least amap), that is we need to care of not only html+css but also javascript which is also important part for gadget functionality. We provided a solution to solve it and it works fine to some extent in our original patch. Would you or some one in this group please to review the solution idea(in the long note above) and give some feedback? note: this solution implementation is not enabled in our new inline feature patch. Thanks a lot. > > On Tue, Nov 2, 2010 at 10:20 PM, ๏̯͡๏ Jasvir Nagra <[email protected] > >wrote: > > > This is just one of the many problems with inlining two or more gadgets > > gets you. The others include but aren't limited to: > > > > * css styles defined in one gadget will apply on other gadgets with > > elements, classes, ids or other selectors that match > > * javascript functions and globals between gadgets that conflict > > * event handlers in one gadget bind to the wrong instance > > * modification of javascript prototype objects in one gadget conflict > with > > others > > * xml namespaces defined in one gadget bleed into another > > > > What you need is to be able to turn a block of html, css and javascript > > into a closed function that you're able to instantiate multiple times, > with > > each instance getting a fresh copy of those properties it wishes to be > able > > to modify. This is the property that Caja gives you. Cajoling a block > of > > html, css and javascript gives you a block of html and javascript that is > > safe for inlining multiple times. The difficulty in the case of Shindig > > (which we are working on resolving and why inlining with Caja is not > checked > > in today) arises not from inlining html and css which are solved problems > > but from exposing the opensocial and other gadget apis to inlined code. > > These apis modify the javascript prototypes and other DOM objects on > behalf > > of gadgets and are a means by which otherwise isolated gadgets may > interfere > > with each other. > > > > On Tue, Nov 2, 2010 at 9:43 PM, Kai Feng Zhang <[email protected]> > wrote: > > > >> The first problem inline gadget rendering needs to solve is about > >> namespacing conflict. > >> > >> Since some gadget declare a unique identifier for some element in dom, > >> such > >> as <div id="hello">, if this gadget is rendered with inline multiple > times > >> on same page, it's a problem of element id conflict. > >> > >> As our former implementation(in original patch to support inline) is > based > >> on the iWidget context concept and request the gadget developer to > rewrite > >> their gadget with a scope, which will generate a unique identifier for > >> each > >> element in inline gadget, to avoid namespacing conflict issue. > >> > >> It might be a little reluctant for gadget developer to accept and it > also > >> needs effort to rewrite thousands of existing gadgets. So we did not > >> enable > >> this implementation in our new inline patch. > >> https://issues.apache.org/jira/browse/SHINDIG-1402 > >> > >> But currently seems we didn't find a better way to solve it. So could > >> someone please review and propose any better way to do solve this > >> namespacing problem? > >> > >> > >> Thanks. > >> > >> Best Regards, > >> > >> Kevin, Zhang Kai Feng > >> IBM Project Vulcan Development > >> IBM China Software Development Lab > >> > >> > >> > >> On Wed, Nov 3, 2010 at 12:29 PM, Kai Feng Zhang <[email protected]> > >> wrote: > >> > >> > Hi, > >> > > >> > We originally posted inlining work directly into the existing > container > >> > shindig-container/server side components... see > >> > https://issues.apache.org/jira/browse/SHINDIG-1402 > >> > > >> > After reviewing some of these changes and learning more about the > >> features, > >> > we've stepped back and refactored those changes as a feature on the > >> common > >> > container. I add a new patch, which is based on new common container > as > >> well > >> > as its new patch: https://issues.apache.org/jira/browse/SHINDIG-1460 > >> > > >> > After apply the patch, access > >> > http://localhost:8080/container/helloworld_common3.html you would see > >> the > >> > inline gadget and iframe gadget being rendered on same page, though > they > >> are > >> > helloworld gadgets. Gadget requires "inline" feature will be rendered > >> as > >> > inline one. > >> > > >> > Have to say that introducing inline rendering would cause much problem > >> for > >> > gadget features, since most of them are design specially for iframe > >> > rendering gadget. We will post the impacted aspects in following > >> comments. > >> > > >> > > >> > > >> > Best Regards, > >> > > >> > Kevin, Zhang Kai Feng > >> > IBM Project Vulcan Development > >> > IBM China Software Development Lab > >> > > >> > > >> > > > > >
