Caja gadgets without iframes?

[Abe Music <ab...@gmail.com>]

Hello all,

I'm new to the list, but have been using shindig for a while, however,
my involvement up to this point has only been writing gadgets and
handing them off to shindig for rendering. I have recently been tasked
with creating a "secure" container using the Caja project with
Shindig. I've started messing around with the caja feature and have
verified that it works enough for us to get started with our project,
but I have a few architecture-related issues I need to get clarified
before moving forward.

I understand that Shindig renders gadgets in their own iframes for
security reasons, however, since we will be leveraging caja to provide
"virtual sandboxes" we would like to remove this iframe dependency and
stuff the gadget content directly into HTML elements instead. The
overall look and feel to the container page would be exactly the same.
It should also reduce the overhead of the containing page and assuming
that Caja lives up to its name the iframe shouldn't be required any
longer. So, here I am trying to wrap my head around the idea of using
shindig to supply rendered gadget content to my container page. I
anticipate that this will require changes to both the server and
client aspects of Shindig as well as the caja feature, but I wanted to
pose my thoughts to the group before moving forward.

I'm thinking the workflow for my project would go like this:

1) Build an HTML page that defines all gadgets that need to be
rendered and kickstart the rendering process through XHR?. This page
would need to have the Valija runtime to support cajoled gadget code
and somehow make the runtime aware of all gadgets as they are
rendered.

2) For each gadget to be rendered I would somehow have Shindig supply
the DHTML of the rendered gadget directly instead of in an iframe

3) Using that DHTML I would somehow leverage the Valija runtime to
build out the cajoled gadget in separate containers in the HTML page

4) We now have a secure container page? Yeah, that sounds about right...

Now then, #1 I believe is trivial, but #2 and #3 are where things
start getting hairy. For #3 we no longer stuff the content into an
iframe by supplying the src parameter and having shindig build out
rendered gadget code on the fly for the iframe to present. Instead the
rendered gadget code would have to be stuffed into the containing html
elements manually at runtime on the containing page. It can't possibly
be as simple as asynchronously requesting rendered gadget code (via
the /gadgets/ifr URL ???) from shindig and stuffing the response
(DHTML) into a div via setting its innerHTML property? The rendered
gadget content using the caja feature bakes all required code into the
content (domita, valija , etc), therefore, a lot of the supporting
feature code would need to be modified to produce only the code that
should be dumped in the html element and leave Caja-runtime tasks up
to the containing page. Also, does anything on the server side need to
change? Shindig, to my knowledge, is not responsible for creating any
iframes or handling anything special on behalf of the client side, but
I really don't know.

General questions:

1) What needs to be done on my part? I'm perfectly fine with knocking
out some code to support my efforts, but I really need to be pointed
in the right direction.

2) If I am to modify the caja feature to support what I'm trying to do
would it be best to only have the gadget renderer cajole the gadget
and only return the JS as a script and asynchronously load those in
the containing page? I'm thinking something along the lines of:
<script src="/gadgets/ifr?url=..."></script>

3) Anything else I need to be aware of? I would really like to get a
good discussion going so that we (Shindig, Caja, and my project) can
start hashing out what it's going to take to get where we need to be.
I can't possibly think that my questions are original (in fact I found
a few threads on this very thing), but I would really like to help
move things along so everyone can benefit. I think that both Shindig
and Caja are both great projects and would love to see something like
what I've described start coming to fruition. If there are projects
out there doing similar work that anyone knows of please let me know!

Thanks for the help!

-- Abe

Re: Caja gadgets without iframes?

[Kevin Brown <et...@google.com>]

On Thu, Jul 30, 2009 at 12:32 PM, Abe Music <ab...@gmail.com> wrote:

> Kevin,
>
> Thanks for the reply! It sounds like this is something you've thought
> about before :) Hopefully a few more questions is all I need to ask
> and I can get underway with some code. I'm looking into some code that
> extends the GadgetContext that you recommend (HttpGadgetContext,
> OAuthGadgetContext, and JsonRpcGadgetContext) and I'm just struggling
> with understanding the overall architecture of Shindig and how
> everything plays with each other. Is there a wiki or some
> documentation that details how GadgeContexts work with Renderers and
> everything? If not that's OK too, but just trying to get up to speed
> as fast as possible.


A GadgetContext is just an abstraction over input so that the processing for
a Renderer can be normalized (as the documentation indicates).


>
>
> One other thing...It looks as though the GadgetRenderingServlet is
> what takes advantage of the HttpGadgetContext....I probably shouldn't
> replace that GadgetContext with my own right? I'm thinking that I need
> to "call" my custom GadgetContext from my container somehow, but not
> sure how to invoke it. Any suggestions or point in the right direction
> would be much appreciated.


The simplest way is something like this:

out.write("<html><body>");
for (SomeArguments args : gadgetsToRender) {
  GadgetContext context = new MyCustomCajoledGadgetContext(args);
  RenderingResults result = renderer.render(context);
  if (result.getStatus() == RenderingResults.OK) {
    emitGadgetContent(result.getContent());
  }
}
out.write("</body></html>");

shindig was designed to be used as a library, so you should be able to do
everything without touching any servlets. The servlets are merely light
wrappers around the actual interesting code.

You could always do this through some ajax call as well, but that would be a
bit more complicated.


>
>
> Thanks again!
>
> -- Abe
>
> On Thu, Jul 30, 2009 at 12:29 PM, Kevin Brown<et...@google.com> wrote:
> > If you're using java shindig, you can do this pretty trivially:
> >
> > 1. Create a custom GadgetContext and have getParameter("caja") return
> "1".
> > 2. Feed this into the "Renderer" class.
> > 3. The result is a cajoled gadget.
> >
> > Now, there are a few caveats:
> >
> > - In the current shindig setup, caja is very expensive. This is because
> we
> > parse, serialize, parse, serialize, and parse again when cajoling. The
> caja
> > developers have promised a change to their interfaces that will eliminate
> > this overhead, but it's not in yet.
> >
> > - Many gadget libraries are not tamed, so you'll want to tread carefully
> > when it comes to which gadgets you choose to render in this manner. Stick
> > with gadgets.io, gadgets.util, and opensocial.* and you'll be fine.
> osapi,
> > and most "legacy" features aren't tamed yet, though you could do this
> work
> > yourself if you need to support them.
> >
> > - gadgets.rpc won't work out of the box. You could probably just replace
> it
> > with a simple implementation that calls the same domain.
> >
> > - Many gadget libraries assume that they are the only library in the
> page.
> > It might be easier to just cajole the shindig libraries along with the
> > gadget rather than trying to tame them.
> >
> > On Thu, Jul 30, 2009 at 8:53 AM, Abe Music <ab...@gmail.com> wrote:
> >
> >> Hello all,
> >>
> >> I'm new to the list, but have been using shindig for a while, however,
> >> my involvement up to this point has only been writing gadgets and
> >> handing them off to shindig for rendering. I have recently been tasked
> >> with creating a "secure" container using the Caja project with
> >> Shindig. I've started messing around with the caja feature and have
> >> verified that it works enough for us to get started with our project,
> >> but I have a few architecture-related issues I need to get clarified
> >> before moving forward.
> >>
> >> I understand that Shindig renders gadgets in their own iframes for
> >> security reasons, however, since we will be leveraging caja to provide
> >> "virtual sandboxes" we would like to remove this iframe dependency and
> >> stuff the gadget content directly into HTML elements instead. The
> >> overall look and feel to the container page would be exactly the same.
> >> It should also reduce the overhead of the containing page and assuming
> >> that Caja lives up to its name the iframe shouldn't be required any
> >> longer. So, here I am trying to wrap my head around the idea of using
> >> shindig to supply rendered gadget content to my container page. I
> >> anticipate that this will require changes to both the server and
> >> client aspects of Shindig as well as the caja feature, but I wanted to
> >> pose my thoughts to the group before moving forward.
> >>
> >> I'm thinking the workflow for my project would go like this:
> >>
> >> 1) Build an HTML page that defines all gadgets that need to be
> >> rendered and kickstart the rendering process through XHR?. This page
> >> would need to have the Valija runtime to support cajoled gadget code
> >> and somehow make the runtime aware of all gadgets as they are
> >> rendered.
> >>
> >> 2) For each gadget to be rendered I would somehow have Shindig supply
> >> the DHTML of the rendered gadget directly instead of in an iframe
> >>
> >> 3) Using that DHTML I would somehow leverage the Valija runtime to
> >> build out the cajoled gadget in separate containers in the HTML page
> >>
> >> 4) We now have a secure container page? Yeah, that sounds about right...
> >>
> >> Now then, #1 I believe is trivial, but #2 and #3 are where things
> >> start getting hairy. For #3 we no longer stuff the content into an
> >> iframe by supplying the src parameter and having shindig build out
> >> rendered gadget code on the fly for the iframe to present. Instead the
> >> rendered gadget code would have to be stuffed into the containing html
> >> elements manually at runtime on the containing page. It can't possibly
> >> be as simple as asynchronously requesting rendered gadget code (via
> >> the /gadgets/ifr URL ???)
> >
> >
> > /gadgets/ifr would have a bunch of other stuff that you definitely
> wouldn't
> > want. Try my steps above and you should be good, though.
> >
> >
> >> from shindig and stuffing the response
> >> (DHTML) into a div via setting its innerHTML property? The rendered
> >> gadget content using the caja feature bakes all required code into the
> >> content (domita, valija , etc), therefore, a lot of the supporting
> >> feature code would need to be modified to produce only the code that
> >> should be dumped in the html element and leave Caja-runtime tasks up
> >> to the containing page. Also, does anything on the server side need to
> >> change? Shindig, to my knowledge, is not responsible for creating any
> >> iframes or handling anything special on behalf of the client side, but
> >> I really don't know.
> >>
> >> General questions:
> >>
> >> 1) What needs to be done on my part? I'm perfectly fine with knocking
> >> out some code to support my efforts, but I really need to be pointed
> >> in the right direction.
> >>
> >> 2) If I am to modify the caja feature to support what I'm trying to do
> >> would it be best to only have the gadget renderer cajole the gadget
> >> and only return the JS as a script and asynchronously load those in
> >> the containing page? I'm thinking something along the lines of:
> >> <script src="/gadgets/ifr?url=..."></script>
> >>
> >> 3) Anything else I need to be aware of? I would really like to get a
> >> good discussion going so that we (Shindig, Caja, and my project) can
> >> start hashing out what it's going to take to get where we need to be.
> >> I can't possibly think that my questions are original (in fact I found
> >> a few threads on this very thing), but I would really like to help
> >> move things along so everyone can benefit. I think that both Shindig
> >> and Caja are both great projects and would love to see something like
> >> what I've described start coming to fruition. If there are projects
> >> out there doing similar work that anyone knows of please let me know!
> >>
> >> Thanks for the help!
> >>
> >> -- Abe
> >>
> >
>

Re: Caja gadgets without iframes?

[Abe Music <ab...@gmail.com>]

Kevin,

Thanks for the reply! It sounds like this is something you've thought
about before :) Hopefully a few more questions is all I need to ask
and I can get underway with some code. I'm looking into some code that
extends the GadgetContext that you recommend (HttpGadgetContext,
OAuthGadgetContext, and JsonRpcGadgetContext) and I'm just struggling
with understanding the overall architecture of Shindig and how
everything plays with each other. Is there a wiki or some
documentation that details how GadgeContexts work with Renderers and
everything? If not that's OK too, but just trying to get up to speed
as fast as possible.

One other thing...It looks as though the GadgetRenderingServlet is
what takes advantage of the HttpGadgetContext....I probably shouldn't
replace that GadgetContext with my own right? I'm thinking that I need
to "call" my custom GadgetContext from my container somehow, but not
sure how to invoke it. Any suggestions or point in the right direction
would be much appreciated.

Thanks again!

-- Abe

On Thu, Jul 30, 2009 at 12:29 PM, Kevin Brown<et...@google.com> wrote:
> If you're using java shindig, you can do this pretty trivially:
>
> 1. Create a custom GadgetContext and have getParameter("caja") return "1".
> 2. Feed this into the "Renderer" class.
> 3. The result is a cajoled gadget.
>
> Now, there are a few caveats:
>
> - In the current shindig setup, caja is very expensive. This is because we
> parse, serialize, parse, serialize, and parse again when cajoling. The caja
> developers have promised a change to their interfaces that will eliminate
> this overhead, but it's not in yet.
>
> - Many gadget libraries are not tamed, so you'll want to tread carefully
> when it comes to which gadgets you choose to render in this manner. Stick
> with gadgets.io, gadgets.util, and opensocial.* and you'll be fine. osapi,
> and most "legacy" features aren't tamed yet, though you could do this work
> yourself if you need to support them.
>
> - gadgets.rpc won't work out of the box. You could probably just replace it
> with a simple implementation that calls the same domain.
>
> - Many gadget libraries assume that they are the only library in the page.
> It might be easier to just cajole the shindig libraries along with the
> gadget rather than trying to tame them.
>
> On Thu, Jul 30, 2009 at 8:53 AM, Abe Music <ab...@gmail.com> wrote:
>
>> Hello all,
>>
>> I'm new to the list, but have been using shindig for a while, however,
>> my involvement up to this point has only been writing gadgets and
>> handing them off to shindig for rendering. I have recently been tasked
>> with creating a "secure" container using the Caja project with
>> Shindig. I've started messing around with the caja feature and have
>> verified that it works enough for us to get started with our project,
>> but I have a few architecture-related issues I need to get clarified
>> before moving forward.
>>
>> I understand that Shindig renders gadgets in their own iframes for
>> security reasons, however, since we will be leveraging caja to provide
>> "virtual sandboxes" we would like to remove this iframe dependency and
>> stuff the gadget content directly into HTML elements instead. The
>> overall look and feel to the container page would be exactly the same.
>> It should also reduce the overhead of the containing page and assuming
>> that Caja lives up to its name the iframe shouldn't be required any
>> longer. So, here I am trying to wrap my head around the idea of using
>> shindig to supply rendered gadget content to my container page. I
>> anticipate that this will require changes to both the server and
>> client aspects of Shindig as well as the caja feature, but I wanted to
>> pose my thoughts to the group before moving forward.
>>
>> I'm thinking the workflow for my project would go like this:
>>
>> 1) Build an HTML page that defines all gadgets that need to be
>> rendered and kickstart the rendering process through XHR?. This page
>> would need to have the Valija runtime to support cajoled gadget code
>> and somehow make the runtime aware of all gadgets as they are
>> rendered.
>>
>> 2) For each gadget to be rendered I would somehow have Shindig supply
>> the DHTML of the rendered gadget directly instead of in an iframe
>>
>> 3) Using that DHTML I would somehow leverage the Valija runtime to
>> build out the cajoled gadget in separate containers in the HTML page
>>
>> 4) We now have a secure container page? Yeah, that sounds about right...
>>
>> Now then, #1 I believe is trivial, but #2 and #3 are where things
>> start getting hairy. For #3 we no longer stuff the content into an
>> iframe by supplying the src parameter and having shindig build out
>> rendered gadget code on the fly for the iframe to present. Instead the
>> rendered gadget code would have to be stuffed into the containing html
>> elements manually at runtime on the containing page. It can't possibly
>> be as simple as asynchronously requesting rendered gadget code (via
>> the /gadgets/ifr URL ???)
>
>
> /gadgets/ifr would have a bunch of other stuff that you definitely wouldn't
> want. Try my steps above and you should be good, though.
>
>
>> from shindig and stuffing the response
>> (DHTML) into a div via setting its innerHTML property? The rendered
>> gadget content using the caja feature bakes all required code into the
>> content (domita, valija , etc), therefore, a lot of the supporting
>> feature code would need to be modified to produce only the code that
>> should be dumped in the html element and leave Caja-runtime tasks up
>> to the containing page. Also, does anything on the server side need to
>> change? Shindig, to my knowledge, is not responsible for creating any
>> iframes or handling anything special on behalf of the client side, but
>> I really don't know.
>>
>> General questions:
>>
>> 1) What needs to be done on my part? I'm perfectly fine with knocking
>> out some code to support my efforts, but I really need to be pointed
>> in the right direction.
>>
>> 2) If I am to modify the caja feature to support what I'm trying to do
>> would it be best to only have the gadget renderer cajole the gadget
>> and only return the JS as a script and asynchronously load those in
>> the containing page? I'm thinking something along the lines of:
>> <script src="/gadgets/ifr?url=..."></script>
>>
>> 3) Anything else I need to be aware of? I would really like to get a
>> good discussion going so that we (Shindig, Caja, and my project) can
>> start hashing out what it's going to take to get where we need to be.
>> I can't possibly think that my questions are original (in fact I found
>> a few threads on this very thing), but I would really like to help
>> move things along so everyone can benefit. I think that both Shindig
>> and Caja are both great projects and would love to see something like
>> what I've described start coming to fruition. If there are projects
>> out there doing similar work that anyone knows of please let me know!
>>
>> Thanks for the help!
>>
>> -- Abe
>>
>

Re: Caja gadgets without iframes?

[Kevin Brown <et...@google.com>]

If you're using java shindig, you can do this pretty trivially:

1. Create a custom GadgetContext and have getParameter("caja") return "1".
2. Feed this into the "Renderer" class.
3. The result is a cajoled gadget.

Now, there are a few caveats:

- In the current shindig setup, caja is very expensive. This is because we
parse, serialize, parse, serialize, and parse again when cajoling. The caja
developers have promised a change to their interfaces that will eliminate
this overhead, but it's not in yet.

- Many gadget libraries are not tamed, so you'll want to tread carefully
when it comes to which gadgets you choose to render in this manner. Stick
with gadgets.io, gadgets.util, and opensocial.* and you'll be fine. osapi,
and most "legacy" features aren't tamed yet, though you could do this work
yourself if you need to support them.

- gadgets.rpc won't work out of the box. You could probably just replace it
with a simple implementation that calls the same domain.

- Many gadget libraries assume that they are the only library in the page.
It might be easier to just cajole the shindig libraries along with the
gadget rather than trying to tame them.

On Thu, Jul 30, 2009 at 8:53 AM, Abe Music <ab...@gmail.com> wrote:

> Hello all,
>
> I'm new to the list, but have been using shindig for a while, however,
> my involvement up to this point has only been writing gadgets and
> handing them off to shindig for rendering. I have recently been tasked
> with creating a "secure" container using the Caja project with
> Shindig. I've started messing around with the caja feature and have
> verified that it works enough for us to get started with our project,
> but I have a few architecture-related issues I need to get clarified
> before moving forward.
>
> I understand that Shindig renders gadgets in their own iframes for
> security reasons, however, since we will be leveraging caja to provide
> "virtual sandboxes" we would like to remove this iframe dependency and
> stuff the gadget content directly into HTML elements instead. The
> overall look and feel to the container page would be exactly the same.
> It should also reduce the overhead of the containing page and assuming
> that Caja lives up to its name the iframe shouldn't be required any
> longer. So, here I am trying to wrap my head around the idea of using
> shindig to supply rendered gadget content to my container page. I
> anticipate that this will require changes to both the server and
> client aspects of Shindig as well as the caja feature, but I wanted to
> pose my thoughts to the group before moving forward.
>
> I'm thinking the workflow for my project would go like this:
>
> 1) Build an HTML page that defines all gadgets that need to be
> rendered and kickstart the rendering process through XHR?. This page
> would need to have the Valija runtime to support cajoled gadget code
> and somehow make the runtime aware of all gadgets as they are
> rendered.
>
> 2) For each gadget to be rendered I would somehow have Shindig supply
> the DHTML of the rendered gadget directly instead of in an iframe
>
> 3) Using that DHTML I would somehow leverage the Valija runtime to
> build out the cajoled gadget in separate containers in the HTML page
>
> 4) We now have a secure container page? Yeah, that sounds about right...
>
> Now then, #1 I believe is trivial, but #2 and #3 are where things
> start getting hairy. For #3 we no longer stuff the content into an
> iframe by supplying the src parameter and having shindig build out
> rendered gadget code on the fly for the iframe to present. Instead the
> rendered gadget code would have to be stuffed into the containing html
> elements manually at runtime on the containing page. It can't possibly
> be as simple as asynchronously requesting rendered gadget code (via
> the /gadgets/ifr URL ???)


/gadgets/ifr would have a bunch of other stuff that you definitely wouldn't
want. Try my steps above and you should be good, though.


> from shindig and stuffing the response
> (DHTML) into a div via setting its innerHTML property? The rendered
> gadget content using the caja feature bakes all required code into the
> content (domita, valija , etc), therefore, a lot of the supporting
> feature code would need to be modified to produce only the code that
> should be dumped in the html element and leave Caja-runtime tasks up
> to the containing page. Also, does anything on the server side need to
> change? Shindig, to my knowledge, is not responsible for creating any
> iframes or handling anything special on behalf of the client side, but
> I really don't know.
>
> General questions:
>
> 1) What needs to be done on my part? I'm perfectly fine with knocking
> out some code to support my efforts, but I really need to be pointed
> in the right direction.
>
> 2) If I am to modify the caja feature to support what I'm trying to do
> would it be best to only have the gadget renderer cajole the gadget
> and only return the JS as a script and asynchronously load those in
> the containing page? I'm thinking something along the lines of:
> <script src="/gadgets/ifr?url=..."></script>
>
> 3) Anything else I need to be aware of? I would really like to get a
> good discussion going so that we (Shindig, Caja, and my project) can
> start hashing out what it's going to take to get where we need to be.
> I can't possibly think that my questions are original (in fact I found
> a few threads on this very thing), but I would really like to help
> move things along so everyone can benefit. I think that both Shindig
> and Caja are both great projects and would love to see something like
> what I've described start coming to fruition. If there are projects
> out there doing similar work that anyone knows of please let me know!
>
> Thanks for the help!
>
> -- Abe
>