RE: 3-legged oAuth

["Ciancetta, Jesse E." <jc...@mitre.org>]

Hi Jasha,

I was thinking of spending some time trying to get Rave generated security tokens working with OpenSocial gadgets -- I know you had done some work on this already but ended up blocked awaiting responses from devs on the shindig list regarding how to integrate custom tokens with the common container.

Would you mind if I go ahead and pick that work up?  I'm referring only to generating security tokens on the Rave side and getting the common container to use them -- not any of the OAuth work that I know you already have well underway.

Thanks,

--Jesse

>-----Original Message-----
>From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
>Sent: Wednesday, June 29, 2011 3:19 AM
>To: rave-dev@incubator.apache.org
>Subject: Re: 3-legged oAuth
>
>On 28 June 2011 21:12, Ciancetta, Jesse E. <jc...@mitre.org> wrote:
>
>>
>> >
>> >We're lost now in the magic that happens inside container.navigateGadget
>> so
>> >I've just posted a question on the Shindig-dev list how we can get an
>> >iframeUrl with a valid security token.
>>
>> I think it may be interesting to figure out how to get the Shindig metadata
>> call to return us a proper security token in the response, but I'm not sure
>> it is actually the we want to approach the problem.  Since we (Rave) are
>> going to be a full standalone container with server side components capable
>> of generating the security tokens ourselves, I think that's actually the way
>> we want to go.  I had wired in the Shindig common container code initially
>> "out of the box" just so we could get things working, but had intended to go
>> back and make changes so that we could do things like set security tokens
>> and user preferences from the Rave side instead of having to rely on
>> metadata calls to Shindig from the client browser for that work -- I just
>> haven't had a chance to get back to it yet.
>>
>
>In Shindig 2 it was possible to call container.addGadget with a gadget
>object that contains the security token. In Shindig 3 this method seems to
>be gone. In the way we're rendering the gadgets I haven't been able to set
>the security token from our side. I agree with you that Rave should provide
>the token and should not rely on the container (Shindig) for that. I'll try
>to find out where we can override this behaviour.
>
>
>
>> I think the confusion (at least what seems somewhat confusing to me) is
>> what the common container is really targeted to do.  I think it's supposed
>> to allow any web page to script include the common container JS code and
>> then start embedding gadgets without having to stand up any other
>> infrastructure (aside from the Shindig server).  But that comes at a cost --
>> using the common container as is (and as we do now) means that:
>>
>> ** You have to run the your container code (Rave in our case) and Shindig
>> on the same host/port to allow the ajax call that the common container
>makes
>> back to Shindig to fetch gadget metadata succeed (otherwise you'll get
>> security exceptions for making cross site Ajax calls).  The only way around
>> that is to stand up some kind of server side proxy on your container domain
>> to proxy the ajax call back to Shindig.
>>
>> ** You have to enable authentication in front of Shindig (at least for the
>> metadata calls) and SSO between your container and Shindig so that the
>> endpoint to generate a security token is secure.  If it were wide open I
>> could generate iframe urls with security tokens embedded in them for
>> whatever users I want.
>>
>> ** Common container has to make the ajax call to fetch gadget metadata on
>> every page render -- and with a full container implementation (like Rave)
>> this really shouldn't be required.  We should be able to cache whatever
>> metadata we need on the server side and send it down to the browser with
>our
>> page response, and we should be able to use it to prime the common
>> container's metadata cache.  I've already got some of that plumbing in place
>> -- so if you look at the source of a rendered Rave page you'll see the
>> "metadata" property on the JS object we push onto the widgets array is
>> populated with the results of a server-side call to the Shindig metadata
>> service.  I think that data could then be used to prime the common
>container
>> metadata cache to eliminate the need to make that call on every request -
>> see the TODO notes in the rave_opensocial.js for more information on how
>> that might be done.
>>
>
>Ah, I wondered why the metadata were on the JS object (as a result from the
>OpensocialWidgetRenderer) but not being used.
>
>
>> So I think in the end we want to use the common container code as a basis
>> to take advantage of whatever existing/common/sharable functionality we
>can,
>> but we'll also need to override some of its default behavior with our own
>> code too.
>>
>> I wish I could dig in deeper right now to help more with this piece but I'm
>> tied up with other work at the moment.  Hopefully this makes sense and
>helps
>> though.  Does this approach sound right to you guys?
>>
>
>It does but I guess it won't be finished in the near future. We first wanted
>to have a working gadget with oAuth in any way on our local machines and
>then start adding functionality in Rave in a proper way. We've got a
>'working' gadget so now I can start looking where the hacks can be replaced
>by proper overrides or look for alternatives.
>
>Jasha

RE: 3-legged oAuth

["Ciancetta, Jesse E." <jc...@mitre.org>]

>-----Original Message-----
>From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
>Sent: Tuesday, August 02, 2011 8:04 AM
>To: rave-dev@incubator.apache.org
>Subject: Re: 3-legged oAuth
>
>BTW I did implement storing tokens in the database (in rave-shindig)

Yup -- I'd seen that come through when you committed it a while ago, but for what I'm looking at I don't think I should be touching any of that.

What I'll be working on is just generating an encrypted security token and passing it off to common container so that it can be added to the iframe url -- none of this will involve any kind of persistence.

More specifically -- my initial thoughts are that in the render method of the o.a.r.provider.opensocial.web.renderer.OpenSocialWidgetRenderer I'll make a call to a new o.a.r.provider.opensocial.service.SecuirtyTokenService to fetch an encrypted security token for the current RegionWidget and then add that token to the widget object we push into the widgets array.

Then on the client side I'll have to find some way to get the common container to use that token.

>On 1 August 2011 22:18, Jasha Joachimsthal
><j....@onehippo.com>wrote:
>
>> Hi Jesse,
>>
>> Indeed I got a stuck in handling the security tokens in Shindig, noticed
>> some changes in the Shindig trunk for oAuth and decided to focus on storing
>> the tokens in the db (which I committed just before I went on holiday). The
>> (working) code I had was too dirty (hacks & hard coded tokens) to commit.
>> This week I won't have time to work on it so go ahead :)
>>
>> Jasha
>>
>>
>>
>> On 1 August 2011 22:13, Ciancetta, Jesse E. <jc...@mitre.org> wrote:
>>
>>> Hi Jasha,
>>>
>>> I was thinking of spending some time trying to get Rave generated security
>>> tokens working with OpenSocial gadgets -- I know you had done some
>work on
>>> this already but ended up blocked awaiting responses from devs on the
>>> shindig list regarding how to integrate custom tokens with the common
>>> container.
>>>
>>> Would you mind if I go ahead and pick that work up?  I'm referring only to
>>> generating security tokens on the Rave side and getting the common
>container
>>> to use them -- not any of the OAuth work that I know you already have
>well
>>> underway.
>>>
>>> Thanks,
>>>
>>> --Jesse
>>>
>>> >-----Original Message-----
>>> >From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
>>> >Sent: Wednesday, June 29, 2011 3:19 AM
>>> >To: rave-dev@incubator.apache.org
>>> >Subject: Re: 3-legged oAuth
>>> >
>>> >On 28 June 2011 21:12, Ciancetta, Jesse E. <jc...@mitre.org> wrote:
>>> >
>>> >>
>>> >> >
>>> >> >We're lost now in the magic that happens inside
>>> container.navigateGadget
>>> >> so
>>> >> >I've just posted a question on the Shindig-dev list how we can get an
>>> >> >iframeUrl with a valid security token.
>>> >>
>>> >> I think it may be interesting to figure out how to get the Shindig
>>> metadata
>>> >> call to return us a proper security token in the response, but I'm not
>>> sure
>>> >> it is actually the we want to approach the problem.  Since we (Rave)
>>> are
>>> >> going to be a full standalone container with server side components
>>> capable
>>> >> of generating the security tokens ourselves, I think that's actually
>>> the way
>>> >> we want to go.  I had wired in the Shindig common container code
>>> initially
>>> >> "out of the box" just so we could get things working, but had intended
>>> to go
>>> >> back and make changes so that we could do things like set security
>>> tokens
>>> >> and user preferences from the Rave side instead of having to rely on
>>> >> metadata calls to Shindig from the client browser for that work -- I
>>> just
>>> >> haven't had a chance to get back to it yet.
>>> >>
>>> >
>>> >In Shindig 2 it was possible to call container.addGadget with a gadget
>>> >object that contains the security token. In Shindig 3 this method seems
>>> to
>>> >be gone. In the way we're rendering the gadgets I haven't been able to
>>> set
>>> >the security token from our side. I agree with you that Rave should
>>> provide
>>> >the token and should not rely on the container (Shindig) for that. I'll
>>> try
>>> >to find out where we can override this behaviour.
>>> >
>>> >
>>> >
>>> >> I think the confusion (at least what seems somewhat confusing to me)
>is
>>> >> what the common container is really targeted to do.  I think it's
>>> supposed
>>> >> to allow any web page to script include the common container JS code
>>> and
>>> >> then start embedding gadgets without having to stand up any other
>>> >> infrastructure (aside from the Shindig server).  But that comes at a
>>> cost --
>>> >> using the common container as is (and as we do now) means that:
>>> >>
>>> >> ** You have to run the your container code (Rave in our case) and
>>> Shindig
>>> >> on the same host/port to allow the ajax call that the common container
>>> >makes
>>> >> back to Shindig to fetch gadget metadata succeed (otherwise you'll get
>>> >> security exceptions for making cross site Ajax calls).  The only way
>>> around
>>> >> that is to stand up some kind of server side proxy on your container
>>> domain
>>> >> to proxy the ajax call back to Shindig.
>>> >>
>>> >> ** You have to enable authentication in front of Shindig (at least for
>>> the
>>> >> metadata calls) and SSO between your container and Shindig so that the
>>> >> endpoint to generate a security token is secure.  If it were wide open
>>> I
>>> >> could generate iframe urls with security tokens embedded in them for
>>> >> whatever users I want.
>>> >>
>>> >> ** Common container has to make the ajax call to fetch gadget
>metadata
>>> on
>>> >> every page render -- and with a full container implementation (like
>>> Rave)
>>> >> this really shouldn't be required.  We should be able to cache whatever
>>> >> metadata we need on the server side and send it down to the browser
>>> with
>>> >our
>>> >> page response, and we should be able to use it to prime the common
>>> >> container's metadata cache.  I've already got some of that plumbing in
>>> place
>>> >> -- so if you look at the source of a rendered Rave page you'll see the
>>> >> "metadata" property on the JS object we push onto the widgets array is
>>> >> populated with the results of a server-side call to the Shindig
>>> metadata
>>> >> service.  I think that data could then be used to prime the common
>>> >container
>>> >> metadata cache to eliminate the need to make that call on every
>request
>>> -
>>> >> see the TODO notes in the rave_opensocial.js for more information on
>>> how
>>> >> that might be done.
>>> >>
>>> >
>>> >Ah, I wondered why the metadata were on the JS object (as a result from
>>> the
>>> >OpensocialWidgetRenderer) but not being used.
>>> >
>>> >
>>> >> So I think in the end we want to use the common container code as a
>>> basis
>>> >> to take advantage of whatever existing/common/sharable functionality
>we
>>> >can,
>>> >> but we'll also need to override some of its default behavior with our
>>> own
>>> >> code too.
>>> >>
>>> >> I wish I could dig in deeper right now to help more with this piece but
>>> I'm
>>> >> tied up with other work at the moment.  Hopefully this makes sense
>and
>>> >helps
>>> >> though.  Does this approach sound right to you guys?
>>> >>
>>> >
>>> >It does but I guess it won't be finished in the near future. We first
>>> wanted
>>> >to have a working gadget with oAuth in any way on our local machines
>and
>>> >then start adding functionality in Rave in a proper way. We've got a
>>> >'working' gadget so now I can start looking where the hacks can be
>>> replaced
>>> >by proper overrides or look for alternatives.
>>> >
>>> >Jasha
>>>
>>
>>

Re: 3-legged oAuth

[Jasha Joachimsthal <j....@onehippo.com>]

BTW I did implement storing tokens in the database (in rave-shindig)

On 1 August 2011 22:18, Jasha Joachimsthal <j....@onehippo.com>wrote:

> Hi Jesse,
>
> Indeed I got a stuck in handling the security tokens in Shindig, noticed
> some changes in the Shindig trunk for oAuth and decided to focus on storing
> the tokens in the db (which I committed just before I went on holiday). The
> (working) code I had was too dirty (hacks & hard coded tokens) to commit.
> This week I won't have time to work on it so go ahead :)
>
> Jasha
>
>
>
> On 1 August 2011 22:13, Ciancetta, Jesse E. <jc...@mitre.org> wrote:
>
>> Hi Jasha,
>>
>> I was thinking of spending some time trying to get Rave generated security
>> tokens working with OpenSocial gadgets -- I know you had done some work on
>> this already but ended up blocked awaiting responses from devs on the
>> shindig list regarding how to integrate custom tokens with the common
>> container.
>>
>> Would you mind if I go ahead and pick that work up?  I'm referring only to
>> generating security tokens on the Rave side and getting the common container
>> to use them -- not any of the OAuth work that I know you already have well
>> underway.
>>
>> Thanks,
>>
>> --Jesse
>>
>> >-----Original Message-----
>> >From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
>> >Sent: Wednesday, June 29, 2011 3:19 AM
>> >To: rave-dev@incubator.apache.org
>> >Subject: Re: 3-legged oAuth
>> >
>> >On 28 June 2011 21:12, Ciancetta, Jesse E. <jc...@mitre.org> wrote:
>> >
>> >>
>> >> >
>> >> >We're lost now in the magic that happens inside
>> container.navigateGadget
>> >> so
>> >> >I've just posted a question on the Shindig-dev list how we can get an
>> >> >iframeUrl with a valid security token.
>> >>
>> >> I think it may be interesting to figure out how to get the Shindig
>> metadata
>> >> call to return us a proper security token in the response, but I'm not
>> sure
>> >> it is actually the we want to approach the problem.  Since we (Rave)
>> are
>> >> going to be a full standalone container with server side components
>> capable
>> >> of generating the security tokens ourselves, I think that's actually
>> the way
>> >> we want to go.  I had wired in the Shindig common container code
>> initially
>> >> "out of the box" just so we could get things working, but had intended
>> to go
>> >> back and make changes so that we could do things like set security
>> tokens
>> >> and user preferences from the Rave side instead of having to rely on
>> >> metadata calls to Shindig from the client browser for that work -- I
>> just
>> >> haven't had a chance to get back to it yet.
>> >>
>> >
>> >In Shindig 2 it was possible to call container.addGadget with a gadget
>> >object that contains the security token. In Shindig 3 this method seems
>> to
>> >be gone. In the way we're rendering the gadgets I haven't been able to
>> set
>> >the security token from our side. I agree with you that Rave should
>> provide
>> >the token and should not rely on the container (Shindig) for that. I'll
>> try
>> >to find out where we can override this behaviour.
>> >
>> >
>> >
>> >> I think the confusion (at least what seems somewhat confusing to me) is
>> >> what the common container is really targeted to do.  I think it's
>> supposed
>> >> to allow any web page to script include the common container JS code
>> and
>> >> then start embedding gadgets without having to stand up any other
>> >> infrastructure (aside from the Shindig server).  But that comes at a
>> cost --
>> >> using the common container as is (and as we do now) means that:
>> >>
>> >> ** You have to run the your container code (Rave in our case) and
>> Shindig
>> >> on the same host/port to allow the ajax call that the common container
>> >makes
>> >> back to Shindig to fetch gadget metadata succeed (otherwise you'll get
>> >> security exceptions for making cross site Ajax calls).  The only way
>> around
>> >> that is to stand up some kind of server side proxy on your container
>> domain
>> >> to proxy the ajax call back to Shindig.
>> >>
>> >> ** You have to enable authentication in front of Shindig (at least for
>> the
>> >> metadata calls) and SSO between your container and Shindig so that the
>> >> endpoint to generate a security token is secure.  If it were wide open
>> I
>> >> could generate iframe urls with security tokens embedded in them for
>> >> whatever users I want.
>> >>
>> >> ** Common container has to make the ajax call to fetch gadget metadata
>> on
>> >> every page render -- and with a full container implementation (like
>> Rave)
>> >> this really shouldn't be required.  We should be able to cache whatever
>> >> metadata we need on the server side and send it down to the browser
>> with
>> >our
>> >> page response, and we should be able to use it to prime the common
>> >> container's metadata cache.  I've already got some of that plumbing in
>> place
>> >> -- so if you look at the source of a rendered Rave page you'll see the
>> >> "metadata" property on the JS object we push onto the widgets array is
>> >> populated with the results of a server-side call to the Shindig
>> metadata
>> >> service.  I think that data could then be used to prime the common
>> >container
>> >> metadata cache to eliminate the need to make that call on every request
>> -
>> >> see the TODO notes in the rave_opensocial.js for more information on
>> how
>> >> that might be done.
>> >>
>> >
>> >Ah, I wondered why the metadata were on the JS object (as a result from
>> the
>> >OpensocialWidgetRenderer) but not being used.
>> >
>> >
>> >> So I think in the end we want to use the common container code as a
>> basis
>> >> to take advantage of whatever existing/common/sharable functionality we
>> >can,
>> >> but we'll also need to override some of its default behavior with our
>> own
>> >> code too.
>> >>
>> >> I wish I could dig in deeper right now to help more with this piece but
>> I'm
>> >> tied up with other work at the moment.  Hopefully this makes sense and
>> >helps
>> >> though.  Does this approach sound right to you guys?
>> >>
>> >
>> >It does but I guess it won't be finished in the near future. We first
>> wanted
>> >to have a working gadget with oAuth in any way on our local machines and
>> >then start adding functionality in Rave in a proper way. We've got a
>> >'working' gadget so now I can start looking where the hacks can be
>> replaced
>> >by proper overrides or look for alternatives.
>> >
>> >Jasha
>>
>
>

Re: 3-legged oAuth

[Jasha Joachimsthal <j....@onehippo.com>]

Hi Jesse,

Indeed I got a stuck in handling the security tokens in Shindig, noticed
some changes in the Shindig trunk for oAuth and decided to focus on storing
the tokens in the db (which I committed just before I went on holiday). The
(working) code I had was too dirty (hacks & hard coded tokens) to commit.
This week I won't have time to work on it so go ahead :)

Jasha



On 1 August 2011 22:13, Ciancetta, Jesse E. <jc...@mitre.org> wrote:

> Hi Jasha,
>
> I was thinking of spending some time trying to get Rave generated security
> tokens working with OpenSocial gadgets -- I know you had done some work on
> this already but ended up blocked awaiting responses from devs on the
> shindig list regarding how to integrate custom tokens with the common
> container.
>
> Would you mind if I go ahead and pick that work up?  I'm referring only to
> generating security tokens on the Rave side and getting the common container
> to use them -- not any of the OAuth work that I know you already have well
> underway.
>
> Thanks,
>
> --Jesse
>
> >-----Original Message-----
> >From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
> >Sent: Wednesday, June 29, 2011 3:19 AM
> >To: rave-dev@incubator.apache.org
> >Subject: Re: 3-legged oAuth
> >
> >On 28 June 2011 21:12, Ciancetta, Jesse E. <jc...@mitre.org> wrote:
> >
> >>
> >> >
> >> >We're lost now in the magic that happens inside
> container.navigateGadget
> >> so
> >> >I've just posted a question on the Shindig-dev list how we can get an
> >> >iframeUrl with a valid security token.
> >>
> >> I think it may be interesting to figure out how to get the Shindig
> metadata
> >> call to return us a proper security token in the response, but I'm not
> sure
> >> it is actually the we want to approach the problem.  Since we (Rave) are
> >> going to be a full standalone container with server side components
> capable
> >> of generating the security tokens ourselves, I think that's actually the
> way
> >> we want to go.  I had wired in the Shindig common container code
> initially
> >> "out of the box" just so we could get things working, but had intended
> to go
> >> back and make changes so that we could do things like set security
> tokens
> >> and user preferences from the Rave side instead of having to rely on
> >> metadata calls to Shindig from the client browser for that work -- I
> just
> >> haven't had a chance to get back to it yet.
> >>
> >
> >In Shindig 2 it was possible to call container.addGadget with a gadget
> >object that contains the security token. In Shindig 3 this method seems to
> >be gone. In the way we're rendering the gadgets I haven't been able to set
> >the security token from our side. I agree with you that Rave should
> provide
> >the token and should not rely on the container (Shindig) for that. I'll
> try
> >to find out where we can override this behaviour.
> >
> >
> >
> >> I think the confusion (at least what seems somewhat confusing to me) is
> >> what the common container is really targeted to do.  I think it's
> supposed
> >> to allow any web page to script include the common container JS code and
> >> then start embedding gadgets without having to stand up any other
> >> infrastructure (aside from the Shindig server).  But that comes at a
> cost --
> >> using the common container as is (and as we do now) means that:
> >>
> >> ** You have to run the your container code (Rave in our case) and
> Shindig
> >> on the same host/port to allow the ajax call that the common container
> >makes
> >> back to Shindig to fetch gadget metadata succeed (otherwise you'll get
> >> security exceptions for making cross site Ajax calls).  The only way
> around
> >> that is to stand up some kind of server side proxy on your container
> domain
> >> to proxy the ajax call back to Shindig.
> >>
> >> ** You have to enable authentication in front of Shindig (at least for
> the
> >> metadata calls) and SSO between your container and Shindig so that the
> >> endpoint to generate a security token is secure.  If it were wide open I
> >> could generate iframe urls with security tokens embedded in them for
> >> whatever users I want.
> >>
> >> ** Common container has to make the ajax call to fetch gadget metadata
> on
> >> every page render -- and with a full container implementation (like
> Rave)
> >> this really shouldn't be required.  We should be able to cache whatever
> >> metadata we need on the server side and send it down to the browser with
> >our
> >> page response, and we should be able to use it to prime the common
> >> container's metadata cache.  I've already got some of that plumbing in
> place
> >> -- so if you look at the source of a rendered Rave page you'll see the
> >> "metadata" property on the JS object we push onto the widgets array is
> >> populated with the results of a server-side call to the Shindig metadata
> >> service.  I think that data could then be used to prime the common
> >container
> >> metadata cache to eliminate the need to make that call on every request
> -
> >> see the TODO notes in the rave_opensocial.js for more information on how
> >> that might be done.
> >>
> >
> >Ah, I wondered why the metadata were on the JS object (as a result from
> the
> >OpensocialWidgetRenderer) but not being used.
> >
> >
> >> So I think in the end we want to use the common container code as a
> basis
> >> to take advantage of whatever existing/common/sharable functionality we
> >can,
> >> but we'll also need to override some of its default behavior with our
> own
> >> code too.
> >>
> >> I wish I could dig in deeper right now to help more with this piece but
> I'm
> >> tied up with other work at the moment.  Hopefully this makes sense and
> >helps
> >> though.  Does this approach sound right to you guys?
> >>
> >
> >It does but I guess it won't be finished in the near future. We first
> wanted
> >to have a working gadget with oAuth in any way on our local machines and
> >then start adding functionality in Rave in a proper way. We've got a
> >'working' gadget so now I can start looking where the hacks can be
> replaced
> >by proper overrides or look for alternatives.
> >
> >Jasha
>