Inline gadget proposal

32 views
Skip to first unread message

goosemanjack

unread,
Feb 17, 2011, 2:29:57 PM2/17/11
to OpenSocial and Gadgets Specification Discussion
Starting a thread on Inline gadgets.

Current proposal here:

http://docs.opensocial.org/display/OSD/Investigate+spec+changes+to+support+inline+gadgets

Current proposal suggests adding @renderTypesSupported attribute to
ModulePrefs tag, and manual DOM element ID manipulation by gadget
developer.

=== from current proposal ===
<ModulePrefs title="hello world" renderTypesSupported="inline,
iframe">
Prefix all the fixed DOM id with _MODULE_ID
=== end from current proposal ===


IMO, this functionality should be exposed as part of the security-
policy feature, not as an attribute heaped on the ModulePrefs tag.
Inline vs. iFrame vs. iFrame in jail domain is ultimately a security
consideration. Fully-trusted gadgets could be completely rendered
inline. Partially trusted gadgets could also be rendered inline if
they are scrubbed of script.

Levels of render trust I see are:

* Untrusted - render as iFrame in Jail domain
* Partial Trust Isolated - render as iFrame to avoid DOM and CSS
collision, jail domain optional
* Partial Trust Inline - render inline with no client
container and all client script stripped out
* Full Trust Inline - render directly inline allowing
scripts

One of the trickiest parts of inline rendering is DOM and CSS
isolation. IMO asking the developer to manually control the DOM
element IDs is the wrong path for two reasons:

1. It is error-prone b/c gadget developers will "forget" or will
ignore this requirement.
2. It disallows multiple instances of the same gadget rendered on the
same page.

DOM and CSS ID manipulation must be handled programmatically to
overcome the two above issues. It's a tricky problem, though, and we
may be able to simply make a recommendation to gadget authors and punt
this aspect to a later spec version.

Currently security policy is defined in the template portion of the
spec. We should also move it to the core gadget spec.

http://opensocial-resources.googlecode.com/svn/spec/1.1/OpenSocial-Templating.xml#rfc.section.6

The security policy only deals with EL escaping behavior in its
current form, but was specifically designed as a module feature to be
extensible. Through additional <param> tags we can extend this to
allow the gadget developer to request inline rendering and any
additional features required.

ex:
<ModulePrefs >
<Optional feature="security-policy">
<Param name="render_inline" >home</Param>
<Param name="render_inline_noscripts" >profile</Param>
</Optional >
</ModulePrefs >


The above syntax allows for finer grained control of rendering
mechanisms on a per-view basis.

rbaxter85

unread,
Feb 17, 2011, 7:50:27 PM2/17/11
to OpenSocial and Gadgets Specification Discussion
Googsemanjack, Grace started a thread here.
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/ff1ceba8a99c9338
You should repost your comments there.

On Feb 17, 2:29 pm, goosemanjack <cc...@myspace.com> wrote:
> Starting a thread on Inline gadgets.
>
> Current proposal here:
>
> http://docs.opensocial.org/display/OSD/Investigate+spec+changes+to+su...
> http://opensocial-resources.googlecode.com/svn/spec/1.1/OpenSocial-Te...

goosemanjack

unread,
Feb 18, 2011, 1:09:36 PM2/18/11
to OpenSocial and Gadgets Specification Discussion
Closing this thread down and posting on the live thread. Please add
all comments on the other thread!!!










On Feb 17, 4:50 pm, rbaxter85 <rbaxte...@gmail.com> wrote:
> Googsemanjack, Grace started a thread here.http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thr...

Mark W.

unread,
Feb 23, 2011, 12:20:21 PM2/23/11
to opensocial-an...@googlegroups.com
+1 for moving security policy.
Reply all
Reply to author
Forward
0 new messages