I uploaded patch here: http://codereview.appspot.com/2927041/ , for code review. Thanks.
On Wed, Nov 3, 2010 at 5:00 PM, Kai Feng Zhang <[email protected]> wrote: > 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 >> >> > >> >> > >> >> >> > >> > >> > >
