You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Kai Feng Zhang <zh...@cn.ibm.com> on 2010/11/03 05:29:53 UTC
Inline gadget rendering as a feature
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
Re: Inline gadget rendering as a feature
Posted by Qiao Yun Sun <su...@cn.ibm.com>.
There are 3 optio
T
Option 1: Rewrite the gadget on the fly, separate conflict element by
O
adding a prefix or leveraging third party client side isolation solutio
such as Caja to do the isolation.
1) Add a prefix to the conflict elemen
1) Add a prefix to the conflict
1
HTML content on server side. ModuleId is unique to each gadget instance,
so use it as a prefix.
Add a prefix to every global function and global
Add a prefix to every
A
1. *Function definition: function methodName(){}
2. *Fin
2. *Find the methodName using regular expression
3. *Global replace methodName to _moduleId_ metho
definition and reference
Add the moduleId prefix as the parent class to al
Add the moduleId prefix a
Find all the fixed DOM id, add a moduleId prefix to the fixed
replace all the references to make it only apply to its self instance.
2) Leverage Caja to do the rewrite (this method isolate on gadet type
level. So it will not fix the conflicting global variable and conflicti
DOM element issue, still need extra work to fix that) Caja is a system
th
that transforms ordinary HTML and JavaScript into a restricted form of
JavaScript. The transformation is called "cajoling", and the result is
"cajoled script". The cajoled script is then run within a security sandb
created in your browser. This provides a way to safely include arbitrary
t
third-party content on any Web page. Seems Caja is more of a JavaScript
scrubbing to prevent malware. Currently Caja works mostly in an iframe,
such as shindig, Yahoo.
Issues when leveraging Caja to render gadget i
Issues when leveraging
I
1. Caja can't support external JavaScript and CSS, n
1
ones.
2. If the gadget is rendered inline, only one gadget instance can w
2. I
2
well. If there are two gadget instance, Caja will report errors when
t
taming the functions at client. As for the same gadget, the cajoled sc
is the same. Still need differentiate them.
3. Rendering inline, the posi
3. Rendering inline, the position of the c
3
Cajoled script did something to change the Dom structure.
Pro: No impac
Pro: No impact to existing gadget. All the rewritten wil
P
the shindig rendering service internally.
Con: This method requires on
Con: This method requires one strong too
C
syntax to do the replace, do the javascript syntax analysis to find the
m
method definition and replacement as well as the fixed DOM id definition.
Currently there isn't a available tool to leverage. Also, to the
develope
developers, they might get confused as their code has been replace
they debug their gadget on the client side.
<Kris>I was hoping we shoul
<Kris>I was hoping we should keep Caja out
<
Cajoling has many limitations tha are still getting worked out. Once
have the base working exploring caja for sandoxing gadgets will be a good
option. Another option is to explore OAHub for sandboxing the gadgets
</K
</Kris>
Option 2: Add additional restriction into gadget XML to isol
Option
O
instances under inline model. Define one scope object to gadget definition
to scope all the JavaScript/CSS/HTML under that object. Each gadget
instan
instance has one scope object. Scope object for each gadget instance
different. This approach requires the gadget developer to adhere to some
guidelines to rewrite their gadget. This approach is similar to IBM iWdget
isolation solution.
The gadget developer only responsible for declaring t
The gadget develop
T
encapsulate the functions to the scope, but not control the instance.
S
Shindig will create the instance and make sure every call is controlled
that instance. Shindig will create a global context and make the scope as
a property just like iWidget. This requires adding a snippet of script
wh
when rendering. To separate the added snippet script and the script in t
gadget, the gadget developer should delegate the life cycle of gadget to
S
Shindig instead of itself. For example, the developer shouldn't call
gad
gadgets.util.registerOnLoadHandleronLoad function on the scope class,
as: this.onLoad = function() {this.getHtml();}; and call this function by
Shindig. The snippet is like: first define a contextImpl object (This will
be implemented as a new feature call core.context to make it can be
utiliz
utilized by rendering in iframe. For if the rewritten gadget need be
rendered in iframe, still need call the onLoad function which is in th
contextImpl.):
function contextImpl(obj,gid){
this.scope = obj;
this
function cont
f
this.scope = obj;
this.scope.c
this.scope.context
this.getGID = function(){re
this.getRootElement = function(){};
th
this.getElementById = function(id,ro
this.onLoad = function(){
gadgets.util.reg
gadgets.util.registerOnLoa
if(obj.onLoad){
obj.onLoad.apply(obj);
}
});
obj.onLoad.apply
}
});
}
};
The c
})
}
};
T
T
other method for developer to use, such as getElementById.etc.
Then w
Then when rendering, Shindig will inject some code to create
T
superclass, like:
__GID__context = new contextImpl(new scopeNam
__GID__context =
_
__GID__context.onLoad(); Common guidelines:
1.Defin
_
1.Define an object to encapsulate the func
1
it from each other. It is important that all JavaScript variables and
fu
functions are scoped down to a gadget instance by using the &this8
JavaScript keyword. This implies that the gadget developer is using an
Scope object which is scoped to each gadget instance.
2. Leverage M
2. Leverage ModuleId as the prefix. Every artifact
2
scoped to its instance id which is the moduleId. This value can be
rep
replaced by the real value at run time.
<div id="__MODULE_ID___cont
<div id="__MODULE_ID___content_div" clas
<div id="0_content_div" class="content"> </div>
This makes the ID attrib
This makes the ID attributes safe against other
instances of the same type. If you are omitting the use of the MODULE
constant, you may experience ID clashes which may result in your gadgets
not working correctly.
3. Define an onLoad function to each gadget, don
3. Define an onLoad f
3
gadgets.util.registerOnLoadHandlerClear and simple to sol
conflict issue.
2) Developers can easily navigate each gadget 's context
2) Developers
2
firebug.
Con:
1) Require gadget developer to rewrite his gadg
Con
C
1)
1
2) Require add an attribute "scope" to the gadget spec and then use t
2
scope value to encapsulate the whole functions.
A sample gadget aft
A sample gadget after rewritten:
//<?xm
A
//<?xml version="1.0" encoding=
/
<Module>
<ModulePrefs title="SampleGadge
<ModulePr
scope="org.apache.shindig.smapleGadget">
<R
<Require feature="settitle"/>
<Require f
<Require feature="dynamic-heig
</ModulePrefs>
<Content type="html">
<![CDA
<Content type="
<![CDATA[
<style type
<style typ
.org-apache-shindig-smapl
.org-apache-shindig-smapleGadget a:visited {color:#5
.org-apache-shindig-smapleGadget .content{ margin: 20px 40px
.org-apache-shindig-smapleGadget .button{
background:none repea
background:none repeat scroll 0 0 Cornflow
margin:0 30px;
}
</style>
<script type="text/j
}
</style>
<
</s
<script t
gadgets.window.setTitle('Communit
org = {apache: {shindig: {smapleGadget: {~}}}};
org.apa
org.apache.shindig.smapleGadget = function (){
var state = 0;
var prefs = new gadgets.Prefs(~
var prefs = new
var entries = prefs.getInt("num_entries");
this
this.getPref = function(){
return prefs;
return prefs;
};
this.c
};
this.cha
t
t
state ++;
};
this.getState
};
this
t
t
alert(state);
};
this.ge
};
this.get
t
t
var params = {};
params[g
params[gadgets.io.
params[gadgets.io.RequestParameters.CONTENT_TYPE] =
gadge
gadgets.io.ContentType.FEED;
params[gadgets.io.Requ
params[gadgets.io.RequestParam
var url = "http:~//localhost:8080/vulcan/shindig/container/community.xml"
gadgets.io.makeRequest(url, this.processRes, params);
};
this.processRe
};
this.processRes = function(obj){
var feed = obj
t
t
var feed = obj.data;
var html =
var html = "";
html
html += "<div><
html += "<div>" + feed.Author + "</div><br>";
if (feed.Entry) {
for (var i = 0; i < feed.Ent
for (var i = 0; i
html += "<div>"
+ "<a target='_blank' href='"
+ "<a target='_b
+ feed.Entry[i].Title
+ "</a> ";
html += "</div>";
}
}
+ "</a> ";
html += "<
html += "</
}
}
document.ge
}
doc
gadgets.window.adjustHeight();
};
this.onLoad = function() {
};
this.onLoad = function()
t
t
this.getHtml();
};
};
};
};
</scri
};
<
<
<div id=
<
<h3>
<span >My Communities</span>
</h3>
<div id="~__GID~__conte
<span
</h3>
<div id="~__GID~__co
<div
<
<input type="button" class="button" value="Change Sta
<
onclick="~__GID~__context.scope.changeState(); return fals
<input type="button" class="button" value="Read State"
onclick
onclick="~__GID~__context.scope.getState(); return false
</div>
~]]>
</Content>
</Module>
Currently we have
<
~]]>
~
</Con
</Module>
Currentl
C
that?
Thanks
Best Regards,
Qiao Yun, Sun(Grace)
IBM Project Vulcan
Than
T
Best Re
Qiao Yun, Su
Q
IBM Project Vulcan De
China Software Development Lab(
Email:sunqy@cn.ibm.com
Tel: (86-10)
Tel: (86-10) 82451085
�n��: �k���s�C
Address: 2F, NO. 28 BUILDING, ZHONG GUAN CUN SOFTWARE PARK, NO.8
DONGBEIWANG WESTEN ROAD, BEIJING, 100
DONGBEIWANG WESTEN ROAD, BEIJING, 100193
From:
�/
From:
�/a � Jasvir Nagra
F
�/
To:
dev@shindig.apache.org
Date:
11/03/20
dev@
Date:
11/03/2010 01:50
11/03/
Subject:
Re: Inline
Re: Inlin
Sorry that was perhaps less than he
S
referenced and I think a few clarifications are needed. I realized ther
is
a mis-interpretation that Caja is primarily aimed at "addressing malwar
a m
and
security concerns". The point is that the accidental problems that y
secu
mention above _are_ the security concerns Caja is concerned with - when
they
occur in trusted code, they cause the functionality to break. We s
occur
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.
If you are willing to ign
class
If you are willing to ignore the jav
I
of
most of the complexity - you be mostly able to isolate html and css by:
mos
* rewriting all ids with a instance-based prefix
* creating a new div
*
* creating a new div with an class id that has an
* clipping to this div (this prevents a gadget from accidentally using
absolute positioning)
* rewriting all classes in the gadget to be scop
* rewriting all classe
prefix
If you are not rewriting javascript, the problem then becomes o
If yo
I
asking
that gadget developers use your apis to get and set html eleme
that ga
gadget (including when setting innerHTML) so that they actually get the
right elements and don't accidentally clobber another gadget instance th
has been inlined.
On Tue, Nov 2, 2010 at 10:20 PM, �/a � Jasvir Nag
On Tue, Nov 2, 2
O
<ja...@google.com>wrote:
> This is just one of the man<ja...@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 <zh...@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 <zh...@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
>> >
>> >
>>
>
>
Re: Inline gadget rendering as a feature
Posted by Kai Feng Zhang <zh...@cn.ibm.com>.
Sorry for the format, I repost as following:
There are 3 options when we investigating the solution of namespacing:
================
Option 1*: Rewrite the gadget on the fly, separate conflict element by
adding a prefix or leveraging third party client side isolation solution,
such as Caja to do the isolation.
1) Add a prefix to the conflict elements when converting gadget XML to HTML
content on server side. ModuleId is unique to each gadget instance, so use
it as a prefix.
*
- Add a prefix to every global function and global variable, steps :
1. *Function definition: function methodName(){}
2. *Find the methodName using regular expression
3. *Global replace methodName to _moduleId_ methodName including the
definition and reference
- Add the moduleId prefix as the parent class to all gadget CSS
- Find all the fixed DOM id, add a moduleId prefix to the fixed id and
replace all the references to make it only apply to its self instance.
2) Leverage Caja to do the rewrite (this method isolate on gadet type level.
So it will not fix the conflicting global variable and conflicting DOM
element issue, still need extra work to fix that) Caja is a system that
transforms ordinary HTML and JavaScript into a restricted form of
JavaScript. The transformation is called "cajoling", and the result is
"cajoled script". The cajoled script is then run within a security sandbox
created in your browser. This provides a way to safely include arbitrary
third-party content on any Web page. Seems Caja is more of a JavaScript
scrubbing to prevent malware. Currently Caja works mostly in an iframe, such
as shindig, Yahoo.
Issues when leveraging Caja to render gadget inline :
1. Caja can't support external JavaScript and CSS, need embed the external
ones.
2. If the gadget is rendered inline, only one gadget instance can work well.
If there are two gadget instance, Caja will report errors when taming the
functions at client. As for the same gadget, the cajoled script is the same.
Still need differentiate them.
3. Rendering inline, the position of the content is not right. Seems the
Cajoled script did something to change the Dom structure.
Pro: No impact to existing gadget. All the rewritten will be handled by the
shindig rendering service internally.
Con: This method requires one strong tool to recogniz HTML/JavaScript/CSS
syntax to do the replace, do the javascript syntax analysis to find the
method definition and replacement as well as the fixed DOM id definition.
Currently there isn't a available tool to leverage. Also, to the developers,
they might get confused as their code has been replaced when they debug
their gadget on the client side.
<Kris>I was hoping we should keep Caja out of our first phase since Cajoling
has many limitations tha are still getting worked out. Once we have the base
working exploring caja for sandoxing gadgets will be a good option. Another
option is to explore OAHub for sandboxing the gadgets </Kris>
*Option 2*: Add additional restriction into gadget XML to isolate the gadget
instances under inline model. Define one scope object to gadget definition
to scope all the JavaScript/CSS/HTML under that object. Each gadget instance
has one scope object. Scope object for each gadget instance are different.
This approach requires the gadget developer to adhere to some guidelines to
rewrite their gadget. This approach is similar to IBM iWdget isolation
solution.
The gadget developer only responsible for declaring the scope class and
encapsulate the functions to the scope, but not control the instance.
Shindig will create the instance and make sure every call is controlled in
that instance. Shindig will create a global context and make the scope as a
property just like iWidget. This requires adding a snippet of script when
rendering. To separate the added snippet script and the script in the
gadget, the gadget developer should delegate the life cycle of gadget to
Shindig instead of itself. For example, the developer shouldn't call
gadgets.util.registerOnLoadHandleronLoad
function on the scope class, such as: this.onLoad = function()
{this.getHtml();}; and call this function by Shindig. The snippet is like:
first define a contextImpl object (This will be implemented as a new feature
call core.context to make it can be utilized by rendering in iframe. For if
the rewritten gadget need be rendered in iframe, still need call the onLoad
function which is in the contextImpl.):
function contextImpl(obj,gid){
this.scope = obj;
this.scope.context = this;
this.getGID = function(){return gid;};
this.getRootElement = function(){};
this.getElementById = function(id,root){};
this.onLoad = function(){
gadgets.util.registerOnLoadHandler(function(){
if(obj.onLoad){
obj.onLoad.apply(obj);
}
});
}
};
The context object will be exposed as a global object and provide some other
method for developer to use, such as getElementById.etc.
Then when rendering, Shindig will inject some code to create the superclass,
like:
__GID__context = new contextImpl(new scopeName(), gid);
__GID__context.onLoad(); Common guidelines:
1.Define an object to encapsulate the functions and variables to protect it
from each other. It is important that all JavaScript variables and functions
are scoped down to a gadget instance by using the “this” JavaScript keyword.
This implies that the gadget developer is using an Scope object which is
scoped to each gadget instance.
2. Leverage ModuleId as the prefix. Every artifact of a gadget must be
scoped to its instance id which is the moduleId. This value can be replaced
by the real value at run time.
<div id="__MODULE_ID___content_div" class="content"> </div> ----------> <div
id="0_content_div" class="content"> </div>
This makes the ID attributes safe against other gadgets and gadgets
instances of the same type. If you are omitting the use of the MODULE_ID
constant, you may experience ID clashes which may result in your gadgets not
working correctly.
3. Define an onLoad function to each gadget, don't call
gadgets.util.registerOnLoadHandlerClear
and simple to solve the namespace conflict issue.
2) Developers can easily navigate each gadget 's context and scope in
firebug.
Con:
1) Require gadget developer to rewrite his gadget if rendering inline.
2) Require add an attribute "scope" to the gadget spec and then use this
scope value to encapsulate the whole functions.
A sample gadget after rewritten:
//<?xml version="1.0" encoding="UTF-8"?>
<Module>
<ModulePrefs title="SampleGadgetWithScope"
scope="org.apache.shindig.smapleGadget">
<Require feature="settitle"/>
<Require feature="dynamic-height"></Require>
</ModulePrefs>
<Content type="html">
<![CDATA[
<style type="text/css">
.org-apache-shindig-smapleGadget a {color:#0000cc;}
.org-apache-shindig-smapleGadget a:visited {color:#551a8b;}
.org-apache-shindig-smapleGadget .content{ margin: 20px 40px;}
.org-apache-shindig-smapleGadget .button{
background:none repeat scroll 0 0 CornflowerBlue;
margin:0 30px;
}
</style>
<script type="text/javascript">
gadgets.window.setTitle('Communities',~__MODULE_ID~__);
org = {apache: {shindig: {smapleGadget: {~}}}};
org.apache.shindig.smapleGadget = function (){
var state = 0;
var prefs = new gadgets.Prefs(~__MODULE_ID~__);
var entries = prefs.getInt("num_entries");
this.getPref = function(){
return prefs;
};
this.changeState = function(){
state ++;
};
this.getState = function(){
alert(state);
};
this.getHtml = function(){
var params = {};
params[gadgets.io.RequestParameters.REFRESH_INTERVAL] = 1;
params[gadgets.io.RequestParameters.CONTENT_TYPE] =
gadgets.io.ContentType.FEED;
params[gadgets.io.RequestParameters.NUM_ENTRIES] = new Number(entries);
var url = "http:~//localhost:8080/vulcan/shindig/container/community.xml";
gadgets.io.makeRequest(url, this.processRes, params);
};
this.processRes = function(obj){
var feed = obj.data;
var html = "";
html += "<div><b>" + feed.Title + "</b></div>";
html += "<div>" + feed.Author + "</div><br>";
if (feed.Entry) {
for (var i = 0; i < feed.Entry.length; i++) {
html += "<div>"
+ "<a target='_blank' href='" + feed.Entry[i].Link + "'>"
+ feed.Entry[i].Title
+ "</a> ";
html += "</div>";
}
}
document.getElementById('~__GID~__content_div').innerHTML = html;
gadgets.window.adjustHeight();
};
this.onLoad = function() {
this.getHtml();
};
};
</script>
<div id="~__GID~__gadget" class="*//org-apache-shindig-smapleGadget*//">
<h3>
<span >My Communities</span>
</h3>
<div id="~__GID~__content_div" class="content"> </div>
<input type="button" class="button" value="Change State"
onclick="~__GID~__context.scope.changeState(); return false;"/>
<input type="button" class="button" value="Read State"
onclick="~__GID~__context.scope.getState(); return false;"/>
</div>
~]]>
</Content>
</Module>
*
**Conclusion**: Option 1 does not impact existing gadget, but do some code
replacement on the fly. For gadget developers, they might get confused as
gadget client side code is rewritten by Shindig server. Option 1 requries a
strong HTML/CSS/JavaScript syntax analysizer. Option 2 add additional
restrictions to gadget spec to support gadget instance isolation with inline
rendering model. It is developer's responsibility to handle the conflict.*
================
Best Regards,
Kevin, Zhang Kai Feng
IBM Project Vulcan Development
IBM China Software Development Lab
2010/11/3 Qiao Yun Sun <su...@cn.ibm.com>
>
>
>
> Option 1: Rewrite the gadget on the fly, separate conflict element
>
> O
> adding a prefix or leveraging third party client side isolation solutio
> such as Caja to do the isolation.
>
> 1) Add a prefix to the conflict elemen
>
> 1) Add a prefix to the conflict
> 1
> HTML content on server side. ModuleId is unique to each gadget instance,
> so use it as a prefix.
>
> * Add a prefix to every global function and
>
> * Add a prefix to
>
>
> 1. *Function definition: function methodName(){}
> 2. *Find the me
>
> 2. *Find the methodName using regular expression
> 3. *Global replace methodName to _moduleId_ metho
> definition and reference
>
> * Add the moduleId prefix as the parent c
>
> * Add the moduleId
>
> * Find all the fixed DOM id, add a moduleId prefix to the fixed
> replace all the references to make it only apply to its self instance.
>
> 2)
>
> 2) Leverage Caja to do the rewrite (this method isolate on gadet type
> 2
> level. So it will not fix the conflicting global variable and conflicti
> DOM element issue, still need extra work to fix that) Caja is a system
> th
> that transforms ordinary HTML and JavaScript into a restricted form of
> JavaScript. The transformation is called "cajoling", and the result is
> "cajoled script". The cajoled script is then run within a security sandb
> created in your browser. This provides a way to safely include arbitrary
> t
> third-party content on any Web page. Seems Caja is more of a JavaScript
>
> scrubbing to prevent malware. Currently Caja works mostly in an iframe,
> such as shindig, Yahoo.
>
> Issues when leveraging Caja to render gadget i
>
> Issues when leveraging
> I
>
> 1. Caja can't support external JavaScript and CSS, n
> 1
> ones.
>
> 2. If the gadget is rendered inline, only one gadget instance can w
>
> 2. I
> 2
> well. If there are two gadget instance, Caja will report errors when
> t
> taming the functions at client. As for the same gadget, the cajoled sc
> is the same. Still need differentiate them.
>
> 3. Rendering inline, the posi
>
> 3. Rendering inline, the position of the c
> 3
> Cajoled script did something to change the Dom structure.
>
> Pro: No impac
>
> Pro: No impact to existing gadget. All the rewritten wil
> P
> the shindig rendering service internally.
>
> Con: This method requires on
>
> Con: This method requires one strong too
> C
> syntax to do the replace, do the javascript syntax analysis to find the
> m
> method definition and replacement as well as the fixed DOM id definition.
> Currently there isn't a available tool to leverage. Also, to the
> develope
> developers, they might get confused as their code has been replace
> they debug their gadget on the client side.
>
> <Kris>I was hoping we shoul
>
> <Kris>I was hoping we should keep Caja out
> <
> Cajoling has many limitations tha are still getting worked out. Once
> have the base working exploring caja for sandoxing gadgets will be a good
> option. Another option is to explore OAHub for sandboxing the gadgets
> </K
> </Kris>
>
> Option 2: Add additional restriction into gadget XML to isol
>
> Option
> O
> instances under inline model. Define one scope object to gadget definition
> to scope all the JavaScript/CSS/HTML under that object. Each gadget
> instan
> instance has one scope object. Scope object for each gadget instance
> different. This approach requires the gadget developer to adhere to some
> guidelines to rewrite their gadget. This approach is similar to IBM iWdget
> isolation solution.
>
> The gadget developer only responsible for declaring t
>
> The gadget develop
> T
> encapsulate the functions to the scope, but not control the instance.
> S
> Shindig will create the instance and make sure every call is controlled
> that instance. Shindig will create a global context and make the scope as
>
> a property just like iWidget. This requires adding a snippet of script
> wh
> when rendering. To separate the added snippet script and the script in t
> gadget, the gadget developer should delegate the life cycle of gadget to
> S
> Shindig instead of itself. For example, the developer shouldn't
> callgadg
> callgadgets.util.registerOnLoadHandleronLoad function on the scop
> such as: this.onLoad = function() {this.getHtml();}; and call this
> functi
> function by Shindig. The snippet is like: first define a contextImpl
> object (This will be implemented as a new feature call core.context to
> make it can be utilized by rendering in iframe. For if the rewritten
> g
> gadget need be rendered in iframe, still need call the onLoad function
> which is in the contextImpl.):
>
> function contextImpl(obj,gid){
> this.s
>
> function contextImpl(obj,gid)
> f
> this.scope = obj;
> this.scope.c
> this.scope.context
> this.getGID = function(){re
> this.getRootElement = function(){};
> th
> this.getElementById = function(id,ro
> this.onLoad = function(){
> gadgets.util.reg
> gadgets.util.registerOnLoa
> if(obj.onLoad){
> obj.onLoad.apply(obj);
> }
> });
> obj.onLoad.apply
> }
> });
> }
> };
>
> The co
> })
> }
> }
> };
>
> T
> T
> other method for developer to use, such as getElementById.etc.
>
> Then w
>
> Then when rendering, Shindig will inject some code to create
> T
> superclass, like:
>
> __GID__context = new contextImpl(new scopeNam
>
> __GID__context =
> _
>
> __GID__context.onLoad(); Common guidelines:
>
> 1.Defin
> _
>
> 1.Define an object to encapsulate the func
> 1
> it from each other. It is important that all JavaScript variables and
> fu
> functions are scoped down to a gadget instance by using the &this 8
>
> JavaScript keyword. This implies that the gadget developer is using an
> Scope object which is scoped to each gadget instance.
>
>
> 2. Leverage M
>
>
> 2. Leverage ModuleId as the prefix. Every artifact
>
> 2
> scoped to its instance id which is the moduleId. This value can be
> rep
> replaced by the real value at run time.
> <div id="__MODULE_ID___cont
> <div id="__MODULE_ID___content_div" clas
> id="0_content_div" class="content"> </div>
> This makes the ID attribute
> This makes the ID attributes safe against o
> instances of the same type. If you are omitting the use of the MODULE
> constant, you may experience ID clashes which may result in your gadgets
> not working correctly.
>
> 3. Define an onLoad function to each gadget, don
>
> 3. Define an onLoad f
> 3
> gadgets.util.registerOnLoadHandlerClear and simple to sol
> conflict issue.
>
> 2) Developers can easily navigate each gadget 's context
>
> 2) Developers
> 2
> firebug.
>
>
>
> Con:
>
> 1) Require gadget developer to rewrite his gadg
>
>
>
> Con
>
>
> C
>
> 1)
> 1
>
> 2) Require add an attribute "scope" to the gadget spec and then use t
> 2
> scope value to encapsulate the whole functions.
>
>
>
> A sample gadget aft
>
>
>
> A sample gadget after rewritten:
>
> <?xml
>
>
> A
>
> <?xml version="1.0" encoding="U
> <
> <Module>
> <ModulePrefs title="SampleGad
> <ModulePr
> scope="org.apache.shindig.smapleGadget">
> <R
> <Require feature="settitle"/>
> <Require f
> <Require feature="dynamic-heig
> </ModulePrefs>
> <Content type="html">
> <![CDA
> <Content type="
> <![CDATA[
> <style type
> <style typ
> .org-apache-shindig-smap
> .org-apache-shindig-smapleGadget a:visited {color:#5
> .org-apache-shindig-smapleGadget .content{ margin: 20px 40px
> .org-apache-shindig-smapleGadget .button{
> background:none repe
> background:none repeat scroll 0 0 Cornflow
> margin:0 30px;
> }
> </style>
> <script type="text/ja
> }
> </style>
> <s
> </
> <script t
> gadgets.window.setTitle('Communi
> org = {apache: {shindig: {smapleGadget: {~}}}};
> org.apa
> org.apache.shindig.smapleGadget = function (){
>
> var state = 0;
> var prefs = new gadgets.Prefs(~
> var prefs = new
> var entries = prefs.getInt("num_entries");
> this
> this.getPref = function(){
> return prefs;
>
> return prefs;
> };
>
> this.c
> };
>
> this.cha
>
> t
> t
> state ++;
> };
>
> this.getState
> };
>
> this
>
> t
> t
> alert(state);
> };
>
> this.ge
> };
>
> this.get
>
> t
> t
> var params = {};
> params[ga
> params[gadgets.io
> params[gadgets.io.RequestParameters.CONTENT_TYPE] =
> gadge
> gadgets.io.ContentType.FEED;
> params[gadgets.io.Reque
> params[gadgets.io.RequestPara
> var url = "http:~//localhost:8080/vulcan/shindig/container/community.xml
> gadgets.io.makeRequest(url, this.processRes, params);
> };
>
> this.processRe
> };
>
> this.processRes = function(obj){
> var feed = obj
>
> t
> t
> var feed = obj.data;
> var html =
> var html = "";
> html
> html += "<div><
> html += "<div>" + feed.Author + "</div><br>";
> i
> if (feed.Entry) {
> for (var i = 0; i < feed.En
> for (var i = 0; i
> html += "<div>"
> + "<a target='_blank' href='"
> + "<a target='_b
> + feed.Entry[i].Title
> + "</a> ";
> html += "</div>";
> }
> }
> + "</a> ";
> html += "<
> html += "</
> }
> }
> document.get
> }
> do
> gadgets.window.adjustHeight();
> };
>
> this.onLoad = function() {
>
> };
>
> this.onLoad = function()
>
> t
> t
> this.getHtml();
> };
> };
>
>
> };
> };
>
> </scri
> };
>
> <
> <
>
> <div id=
> <
> <h3>
> <span >My Communities</span>
> </h3>
>
> <div id="~__GID~__content_
> <span
> </h3>
>
> <div id="~__GID~__co
>
> <div
> <
>
> <input type="button" class="button" value="Change Sta
> <
> onclick="~__GID~__context.scope.changeState(); return fals
> <input type="button" class="button" value="Read State"
> onclick
> onclick="~__GID~__context.scope.getState(); return false
>
> </div>
>
> ]]>
> </Content>
> </Module>
>
>
> Conclusion: Optio
> <
>
> ]]>
>
> ]
> </Co
> </Module>
>
>
>
> Conclu
>
> C
> replacement on the fly. For gadget developers, they might get confused a
> gadget client side code is rewritten by Shindig server. Option 1 requries
> a strong HTML/CSS/JavaScript syntax analysizer. Option 2 add additional
> r
> restrictions to gadget spec to support gadget instance isolation with
> i
> inline rendering model. It is developer's responsibility to handle the
> conflict.
>
> Do you think it make sense?
>
>
> Thanks
> Best Regards,
>
> Q
>
> Do you t
> D
>
>
> Thanks
> Best Regards,
>
>
> T
> Best Re
>
> Qiao Yun, Su
> Q
> IBM Project Vulcan De
> China Software Development Lab(
> Email:sunqy@cn.ibm.com <Em...@cn.ibm.com>
> Tel: (86-10)
> Tel: (86-10) 82451085
>
>
> 抧 毈: 杒 嫗 巗 奀
>
> Address: 2F, NO. 28 BUILDING, ZHONG GUAN CUN SOFTWARE PARK, NO.8
> DONGBEIWANG WESTEN ROAD, BEIJING, 100Address: 2F, NO. 28 BUILDING, ZHONG
> GUAN CUN SOFTWARE PARK, NO.8
> DONGBEIWANG WESTEN ROAD, BEIJING, 100193
>
>
>
>
>
> From:
> Jasvir Nagra <ja...@google.com>
> To:
> dev@shindig.apache.org
> Date:
> 11/03/2010 01:50 PM
> Subject:
> Re: Inline gadget rendering as a feature
>
>
>
> 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.
>
> 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.
>
> On Tue, Nov 2, 2010 at 10:20 PM Jasvir Nagra <ja...@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 <zh...@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 <zh...@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
> >> >
> >> >
> >>
> >
> >
>
>
>
>
Re: Inline gadget rendering as a feature
Posted by Qiao Yun Sun <su...@cn.ibm.com>.
Option 1: Rewrite the gadget on the fly, separate conflict element
O
adding a prefix or leveraging third party client side isolation solutio
such as Caja to do the isolation.
1) Add a prefix to the conflict elemen
1) Add a prefix to the conflict
1
HTML content on server side. ModuleId is unique to each gadget instance,
so use it as a prefix.
* Add a prefix to every global function and
* Add a prefix to
1. *Function definition: function methodName(){}
2. *Find the me
2. *Find the methodName using regular expression
3. *Global replace methodName to _moduleId_ metho
definition and reference
* Add the moduleId prefix as the parent c
* Add the moduleId
* Find all the fixed DOM id, add a moduleId prefix to the fixed
replace all the references to make it only apply to its self instance.
2)
2) Leverage Caja to do the rewrite (this method isolate on gadet type
2
level. So it will not fix the conflicting global variable and conflicti
DOM element issue, still need extra work to fix that) Caja is a system
th
that transforms ordinary HTML and JavaScript into a restricted form of
JavaScript. The transformation is called "cajoling", and the result is
"cajoled script". The cajoled script is then run within a security sandb
created in your browser. This provides a way to safely include arbitrary
t
third-party content on any Web page. Seems Caja is more of a JavaScript
scrubbing to prevent malware. Currently Caja works mostly in an iframe,
such as shindig, Yahoo.
Issues when leveraging Caja to render gadget i
Issues when leveraging
I
1. Caja can't support external JavaScript and CSS, n
1
ones.
2. If the gadget is rendered inline, only one gadget instance can w
2. I
2
well. If there are two gadget instance, Caja will report errors when
t
taming the functions at client. As for the same gadget, the cajoled sc
is the same. Still need differentiate them.
3. Rendering inline, the posi
3. Rendering inline, the position of the c
3
Cajoled script did something to change the Dom structure.
Pro: No impac
Pro: No impact to existing gadget. All the rewritten wil
P
the shindig rendering service internally.
Con: This method requires on
Con: This method requires one strong too
C
syntax to do the replace, do the javascript syntax analysis to find the
m
method definition and replacement as well as the fixed DOM id definition.
Currently there isn't a available tool to leverage. Also, to the
develope
developers, they might get confused as their code has been replace
they debug their gadget on the client side.
<Kris>I was hoping we shoul
<Kris>I was hoping we should keep Caja out
<
Cajoling has many limitations tha are still getting worked out. Once
have the base working exploring caja for sandoxing gadgets will be a good
option. Another option is to explore OAHub for sandboxing the gadgets
</K
</Kris>
Option 2: Add additional restriction into gadget XML to isol
Option
O
instances under inline model. Define one scope object to gadget definition
to scope all the JavaScript/CSS/HTML under that object. Each gadget
instan
instance has one scope object. Scope object for each gadget instance
different. This approach requires the gadget developer to adhere to some
guidelines to rewrite their gadget. This approach is similar to IBM iWdget
isolation solution.
The gadget developer only responsible for declaring t
The gadget develop
T
encapsulate the functions to the scope, but not control the instance.
S
Shindig will create the instance and make sure every call is controlled
that instance. Shindig will create a global context and make the scope as
a property just like iWidget. This requires adding a snippet of script
wh
when rendering. To separate the added snippet script and the script in t
gadget, the gadget developer should delegate the life cycle of gadget to
S
Shindig instead of itself. For example, the developer shouldn't
callgadg
callgadgets.util.registerOnLoadHandleronLoad function on the scop
such as: this.onLoad = function() {this.getHtml();}; and call this
functi
function by Shindig. The snippet is like: first define a contextImpl
object (This will be implemented as a new feature call core.context to
make it can be utilized by rendering in iframe. For if the rewritten
g
gadget need be rendered in iframe, still need call the onLoad function
which is in the contextImpl.):
function contextImpl(obj,gid){
this.s
function contextImpl(obj,gid)
f
this.scope = obj;
this.scope.c
this.scope.context
this.getGID = function(){re
this.getRootElement = function(){};
th
this.getElementById = function(id,ro
this.onLoad = function(){
gadgets.util.reg
gadgets.util.registerOnLoa
if(obj.onLoad){
obj.onLoad.apply(obj);
}
});
obj.onLoad.apply
}
});
}
};
The co
})
}
}
};
T
T
other method for developer to use, such as getElementById.etc.
Then w
Then when rendering, Shindig will inject some code to create
T
superclass, like:
__GID__context = new contextImpl(new scopeNam
__GID__context =
_
__GID__context.onLoad(); Common guidelines:
1.Defin
_
1.Define an object to encapsulate the func
1
it from each other. It is important that all JavaScript variables and
fu
functions are scoped down to a gadget instance by using the &this8
JavaScript keyword. This implies that the gadget developer is using an
Scope object which is scoped to each gadget instance.
2. Leverage M
2. Leverage ModuleId as the prefix. Every artifact
2
scoped to its instance id which is the moduleId. This value can be
rep
replaced by the real value at run time.
<div id="__MODULE_ID___cont
<div id="__MODULE_ID___content_div" clas
id="0_content_div" class="content"> </div>
This makes the ID attribute
This makes the ID attributes safe against o
instances of the same type. If you are omitting the use of the MODULE
constant, you may experience ID clashes which may result in your gadgets
not working correctly.
3. Define an onLoad function to each gadget, don
3. Define an onLoad f
3
gadgets.util.registerOnLoadHandlerClear and simple to sol
conflict issue.
2) Developers can easily navigate each gadget 's context
2) Developers
2
firebug.
Con:
1) Require gadget developer to rewrite his gadg
Con
C
1)
1
2) Require add an attribute "scope" to the gadget spec and then use t
2
scope value to encapsulate the whole functions.
A sample gadget aft
A sample gadget after rewritten:
<?xml
A
<?xml version="1.0" encoding="U
<
<Module>
<ModulePrefs title="SampleGad
<ModulePr
scope="org.apache.shindig.smapleGadget">
<R
<Require feature="settitle"/>
<Require f
<Require feature="dynamic-heig
</ModulePrefs>
<Content type="html">
<![CDA
<Content type="
<![CDATA[
<style type
<style typ
.org-apache-shindig-smap
.org-apache-shindig-smapleGadget a:visited {color:#5
.org-apache-shindig-smapleGadget .content{ margin: 20px 40px
.org-apache-shindig-smapleGadget .button{
background:none repe
background:none repeat scroll 0 0 Cornflow
margin:0 30px;
}
</style>
<script type="text/ja
}
</style>
<s
</
<script t
gadgets.window.setTitle('Communi
org = {apache: {shindig: {smapleGadget: {~}}}};
org.apa
org.apache.shindig.smapleGadget = function (){
var state = 0;
var prefs = new gadgets.Prefs(~
var prefs = new
var entries = prefs.getInt("num_entries");
this
this.getPref = function(){
return prefs;
return prefs;
};
this.c
};
this.cha
t
t
state ++;
};
this.getState
};
this
t
t
alert(state);
};
this.ge
};
this.get
t
t
var params = {};
params[ga
params[gadgets.io
params[gadgets.io.RequestParameters.CONTENT_TYPE] =
gadge
gadgets.io.ContentType.FEED;
params[gadgets.io.Reque
params[gadgets.io.RequestPara
var url = "http:~//localhost:8080/vulcan/shindig/container/community.xml
gadgets.io.makeRequest(url, this.processRes, params);
};
this.processRe
};
this.processRes = function(obj){
var feed = obj
t
t
var feed = obj.data;
var html =
var html = "";
html
html += "<div><
html += "<div>" + feed.Author + "</div><br>";
i
if (feed.Entry) {
for (var i = 0; i < feed.En
for (var i = 0; i
html += "<div>"
+ "<a target='_blank' href='"
+ "<a target='_b
+ feed.Entry[i].Title
+ "</a> ";
html += "</div>";
}
}
+ "</a> ";
html += "<
html += "</
}
}
document.get
}
do
gadgets.window.adjustHeight();
};
this.onLoad = function() {
};
this.onLoad = function()
t
t
this.getHtml();
};
};
};
};
</scri
};
<
<
<div id=
<
<h3>
<span >My Communities</span>
</h3>
<div id="~__GID~__content_
<span
</h3>
<div id="~__GID~__co
<div
<
<input type="button" class="button" value="Change Sta
<
onclick="~__GID~__context.scope.changeState(); return fals
<input type="button" class="button" value="Read State"
onclick
onclick="~__GID~__context.scope.getState(); return false
</div>
]]>
</Content>
</Module>
Conclusion: Optio
<
]]>
]
</Co
</Module>
Conclu
C
replacement on the fly. For gadget developers, they might get confused a
gadget client side code is rewritten by Shindig server. Option 1 requries
a strong HTML/CSS/JavaScript syntax analysizer. Option 2 add additional
r
restrictions to gadget spec to support gadget instance isolation with
i
inline rendering model. It is developer's responsibility to handle the
conflict.
Do you think it make sense?
Thanks
Best Regards,
Q
Do you t
D
Thanks
Best Regards,
T
Best Re
Qiao Yun, Su
Q
IBM Project Vulcan De
China Software Development Lab(
Email:sunqy@cn.ibm.com
Tel: (86-10)
Tel: (86-10) 82451085
�n��: �k���s�C
Address: 2F, NO. 28 BUILDING, ZHONG GUAN CUN SOFTWARE PARK, NO.8
DONGBEIWANG WESTEN ROAD, BEIJING, 100Address: 2F, NO. 28 BUILDING, ZHONG GUAN CUN SOFTWARE PARK, NO.8
DONGBEIWANG WESTEN ROAD, BEIJING, 100193
From:
Jasvir Nagra <ja...@google.com>
To:
dev@shindig.apache.org
Date:
11/03/2010 01:50 PM
Subject:
Re: Inline gadget rendering as a feature
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.
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.
On Tue, Nov 2, 2010 at 10:20 PM Jasvir Nagra <ja...@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 <zh...@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 <zh...@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
>> >
>> >
>>
>
>
Re: Inline gadget rendering as a feature
Posted by ๏̯͡๏ Jasvir Nagra <ja...@google.com>.
Thanks Kai - I'll have a look at this tomorrow.
On Sun, Nov 7, 2010 at 5:42 PM, Kai Feng Zhang <zh...@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 <zh...@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 <ja...@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 <jasvir@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 <zh...@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 <zh...@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
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
> >
>
Re: Inline gadget rendering as a feature
Posted by Kai Feng Zhang <zh...@cn.ibm.com>.
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 <zh...@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 <ja...@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 <jasvir@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 <zh...@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 <zh...@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
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>
>
Re: Inline gadget rendering as a feature
Posted by Kai Feng Zhang <zh...@cn.ibm.com>.
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 <ja...@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 <jasvir@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 <zh...@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 <zh...@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
> >> >
> >> >
> >>
> >
> >
>
Re: Inline gadget rendering as a feature
Posted by ๏̯͡๏ Jasvir Nagra <ja...@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.
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.
On Tue, Nov 2, 2010 at 10:20 PM, ๏̯͡๏ Jasvir Nagra <ja...@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 <zh...@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 <zh...@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
>> >
>> >
>>
>
>
Re: Inline gadget rendering as a feature
Posted by Kai Feng Zhang <zh...@cn.ibm.com>.
Hi Jasvir,
Thank you for this quick response. For your comments:
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.
I am not sure about this part, are you meaning even if we make inline gadget
rendering successfully on page, we will still have problems of osapi and
gadget api support from inline gadget, is it true? Can you please explain
more details? Thanks.
Best Regards,
Kevin, Zhang Kai Feng
IBM Project Vulcan Development
IBM China Software Development Lab
2010/11/3 ๏̯͡๏ Jasvir Nagra <ja...@google.com>
> 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 <zh...@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 <zh...@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
> > >
> > >
> >
>
Re: Inline gadget rendering as a feature
Posted by ๏̯͡๏ Jasvir Nagra <ja...@google.com>.
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 <zh...@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 <zh...@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
> >
> >
>
Re: Inline gadget rendering as a feature
Posted by Kai Feng Zhang <zh...@cn.ibm.com>.
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 <zh...@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
>
>