Thanks Kai - I'll have a look at this tomorrow. On Sun, Nov 7, 2010 at 5:42 PM, Kai Feng Zhang <zhan...@cn.ibm.com> wrote:
> 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 <zhan...@cn.ibm.com> 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 <jas...@google.com> > > > > 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 <jas...@google.com > >> >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 <zhan...@cn.ibm.com> > >> 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 <zhan...@cn.ibm.com> > >> >> 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 > >> >> > > >> >> > > >> >> > >> > > >> > > >> > > > > >
