You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Robert O'neill <ro...@us.ibm.com> on 2012/11/01 22:12:21 UTC
Problem with shindig api in rave
I found an issue using the following shindig api in rave:
gadgets.views.openEmbeddedExperience(resultCallback, navigateCallback,
dataModel, opt_params);
I have a gadget on my rave dashboard. From within this gadget, I call
gadgets.views.openEmbeddedExperience to open a new gadget in a modal
dialog.
When the modal dialog appears, I get the error:
HTTP Status 401 - Malformed security token %st%Invalid security token %st%
My understanding of the issue is that the metadata for this gadget is
not preloaded when this api call is made. Instead, gadget metadata is
fetched once on page load for gadgets that are embedded in the
page. For gadgets that are dynamically added, there will be no
metadata and therefore no security token.
The only way to get around the issue at the moment is to add the
target gadget to the page. This properly preloads the gadget metadata
and retrieves the security token and the call to
gadgets.views.openEmbeddedExperience works as expected. For my use
case, this workaround will not suffice.
I am willing to dig into this issue and provide a fix.
Is there a specific place within the code where I should look first?
Thanks,
Robert O'Neill
Re: Problem with shindig api in rave
Posted by Ryan Baxter <rb...@gmail.com>.
So the endpoint defined in Rave returns both the security token and
metadata, essentially the same thing the Shindig endpoint does today.
On Mon, Nov 19, 2012 at 6:18 PM, Franklin, Matthew B.
<mf...@mitre.org>wrote:
> On 11/19/12 6:11 PM, "Ryan Baxter" <rb...@gmail.com> wrote:
>
> >This was my opinion as well, but after talking to Bob this afternoon it
> >sounded like he found a JIRA from Jesse which stated that Rave container
> >should not be making authenticated requests to the Shindig server, which
> >would be needed to return the security token in the metadata request. I
> >don't have the JIRA handy now but I will connect with Bob tomorrow and
> >forward that on.
>
> In this case, what I was advocating is that the Rave endpoint return a
> valid response with Metadata & token; but the token is generated by Rave
> rather than fetching it realtime from Shindig. This allows the metadata
> requests to be cached on the Rave side and used more efficiently in page
> loads.
>
> >
> >
> >On Mon, Nov 19, 2012 at 6:04 PM, Franklin, Matthew B.
> ><mf...@mitre.org>wrote:
> >
> >> On 11/19/12 5:56 PM, "Ryan Baxter" <rb...@gmail.com> wrote:
> >>
> >> >So you want the security token returned with the metadata like Shindig
> >> >does
> >> >by default?
> >>
> >> IMO, that makes the most sense. Since Rave knows who the owner & viewer
> >> are, it needs to encrypt the token. Since common container will need
> >>both
> >> the metadata and the token and Rave already has a gadget metadata
> >> repository, returning both seems to me like the best way forward, but
> >>that
> >> is just my $0.02.
> >>
> >> >
> >> >On Monday, November 19, 2012, Franklin, Matthew B. wrote:
> >> >
> >> >> On 11/19/12 3:18 PM, "Ryan Baxter"
> >><rbaxter85@apache.org<javascript:;>>
> >> >> wrote:
> >> >>
> >> >> >Matt are you proposing that potentially 2 requests be made when
> >> >>rendering
> >> >> >an embedded experience gadget? One to get the metadata and then
> >>one to
> >> >> >get
> >> >> >a security token?
> >> >>
> >> >> No, I would imagine that the controller would fetch and return
> >>metadata
> >> >> for the gadget as well.
> >> >>
> >> >> >
> >> >> >
> >> >> >On Wed, Nov 14, 2012 at 7:11 AM, Franklin, Matthew B.
> >> >> ><mf...@mitre.org>wrote:
> >> >> >
> >> >> >> >-----Original Message-----
> >> >> >> >From: Ryan Baxter [mailto:rbaxter85@gmail.com]
> >> >> >> >Sent: Wednesday, November 14, 2012 6:15 AM
> >> >> >> >To: dev@rave.apache.org
> >> >> >> >Subject: Re: Problem with shindig api in rave
> >> >> >> >
> >> >> >> >Matt I certainly trust your direction here since I am more of an
> >> >> >>observer
> >> >> >> >when it comes to this project, but shouldn't Rave be able to
> >>handle
> >> >> >>Option
> >> >> >> >2?
> >> >> >>
> >> >> >> The way I was looking at it, you can't know which embedded
> >> >>experiences
> >> >> >> will appear in an activity stream, so you would have to have all
> >> >> >> pre-registered gadgets capable of being rendered as EE on the page
> >> >>with
> >> >> >> valid security tokens. Adding all the metadata and tokens for
> >>this
> >> >>case
> >> >> >> seems inefficient, especially if there are a bunch of gadgets in
> >>the
> >> >> >>store.
> >> >> >>
> >> >> >> >What if today I had a bunch of widgets on a page wouldn't that be
> >> >> >> >essentially the same thing?
> >> >> >>
> >> >> >> You *could* add all the widgets in the store to your page as many
> >> >>times
> >> >> >>as
> >> >> >> you would like, but in practice I don't imagine this would be
> >>common.
> >> >> >> Either way, that is a user action vs a system action.
> >> >> >>
> >> >> >> This is just my $0.02. If others in the community have opinions,
> >> >>please
> >> >> >> share them.
> >> >> >>
> >> >> >> >
> >> >> >> >On Tuesday, November 13, 2012, Franklin, Matthew B. wrote:
> >> >> >> >
> >> >> >> >> >-----Original Message-----
> >> >> >> >> >From: Ryan Baxter [mailto:rbaxter85@apache.org<javascript:;>]
> >> >> >> >> >Sent: Thursday, November 08, 2012 9:48 AM
> >> >> >> >> >To: dev@rave.apache.org <javascript:;>
> >> >> >> >> >Subject: Re: Problem with shindig api in rave
> >> >> >> >> >
> >> >> >> >> >In my opinion option 2 sounds the best and more consistent
> >>with
> >> >>what
> >> >> >> >Rave
> >> >> >> >> >does today. With that said I am not familiar with the code
> >> >>either.
> >> >> >> Can
> >> >> >> >> >some of the other Rave experts weigh in here?
> >> >> >> >>
> >> >> >> >> IMO, trying to push everything to the page that could be used
> >>via
> >> >>EE
> >> >> >> will
> >> >> >> >> not scale well. I think having an endpoint configured that
> >>can
> >> >> >> generate a
> >> >> >> >> security token and retrieve metadata for a gadget would be the
> >> >> >> appropriate
> >> >> >> >> model. I would however, suggest that the endpoint only return
> >>a
> >> >> >>valid
> >> >> >> >> response for gadgets that are registered in the store.
> >> >> >> >>
> >> >> >> >> You can wire in a new controller in the rave-opensocial-client
> >> >> >>project
> >> >> >> by
> >> >> >> >> annotating your controller class with @Controller and add a
> >>method
> >> >> >> >> annotated with @RequestMapping to specify the method and path.
> >> I
> >> >> >>would
> >> >> >> >> also autowire in the existing security token service and just
> >> >>create
> >> >> >>a
> >> >> >> >> "dummy" Region & RegionWidget for security token creation. Of
> >> >> >>course,
> >> >> >> >this
> >> >> >> >> endpoint should only be accessible by an authenticated request,
> >> >>but I
> >> >> >> >> believe the current mappings in applicationContext-security.xml
> >> >>will
> >> >> >> handle
> >> >> >> >> this.
> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >On Tue, Nov 6, 2012 at 2:53 PM, Robert O'neill
> >> >> >> ><roneill@us.ibm.com<javascript:;>>
> >> >> >> >> wrote:
> >> >> >> >> >
> >> >> >> >> >> I have dug a bit further into my issue and have found the
> >> >> >>following.
> >> >> >> >> >>
> >> >> >> >> >> As it is currently implemented, the shindig api
> >> >> >> >> >> gadgets.views.openEmbeddedExperience will not work in rave.
> >> >> >> >> >>
> >> >> >
> >>
> >>
>
>
Re: Problem with shindig api in rave
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 11/19/12 6:11 PM, "Ryan Baxter" <rb...@gmail.com> wrote:
>This was my opinion as well, but after talking to Bob this afternoon it
>sounded like he found a JIRA from Jesse which stated that Rave container
>should not be making authenticated requests to the Shindig server, which
>would be needed to return the security token in the metadata request. I
>don't have the JIRA handy now but I will connect with Bob tomorrow and
>forward that on.
In this case, what I was advocating is that the Rave endpoint return a
valid response with Metadata & token; but the token is generated by Rave
rather than fetching it realtime from Shindig. This allows the metadata
requests to be cached on the Rave side and used more efficiently in page
loads.
>
>
>On Mon, Nov 19, 2012 at 6:04 PM, Franklin, Matthew B.
><mf...@mitre.org>wrote:
>
>> On 11/19/12 5:56 PM, "Ryan Baxter" <rb...@gmail.com> wrote:
>>
>> >So you want the security token returned with the metadata like Shindig
>> >does
>> >by default?
>>
>> IMO, that makes the most sense. Since Rave knows who the owner & viewer
>> are, it needs to encrypt the token. Since common container will need
>>both
>> the metadata and the token and Rave already has a gadget metadata
>> repository, returning both seems to me like the best way forward, but
>>that
>> is just my $0.02.
>>
>> >
>> >On Monday, November 19, 2012, Franklin, Matthew B. wrote:
>> >
>> >> On 11/19/12 3:18 PM, "Ryan Baxter"
>><rbaxter85@apache.org<javascript:;>>
>> >> wrote:
>> >>
>> >> >Matt are you proposing that potentially 2 requests be made when
>> >>rendering
>> >> >an embedded experience gadget? One to get the metadata and then
>>one to
>> >> >get
>> >> >a security token?
>> >>
>> >> No, I would imagine that the controller would fetch and return
>>metadata
>> >> for the gadget as well.
>> >>
>> >> >
>> >> >
>> >> >On Wed, Nov 14, 2012 at 7:11 AM, Franklin, Matthew B.
>> >> ><mf...@mitre.org>wrote:
>> >> >
>> >> >> >-----Original Message-----
>> >> >> >From: Ryan Baxter [mailto:rbaxter85@gmail.com]
>> >> >> >Sent: Wednesday, November 14, 2012 6:15 AM
>> >> >> >To: dev@rave.apache.org
>> >> >> >Subject: Re: Problem with shindig api in rave
>> >> >> >
>> >> >> >Matt I certainly trust your direction here since I am more of an
>> >> >>observer
>> >> >> >when it comes to this project, but shouldn't Rave be able to
>>handle
>> >> >>Option
>> >> >> >2?
>> >> >>
>> >> >> The way I was looking at it, you can't know which embedded
>> >>experiences
>> >> >> will appear in an activity stream, so you would have to have all
>> >> >> pre-registered gadgets capable of being rendered as EE on the page
>> >>with
>> >> >> valid security tokens. Adding all the metadata and tokens for
>>this
>> >>case
>> >> >> seems inefficient, especially if there are a bunch of gadgets in
>>the
>> >> >>store.
>> >> >>
>> >> >> >What if today I had a bunch of widgets on a page wouldn't that be
>> >> >> >essentially the same thing?
>> >> >>
>> >> >> You *could* add all the widgets in the store to your page as many
>> >>times
>> >> >>as
>> >> >> you would like, but in practice I don't imagine this would be
>>common.
>> >> >> Either way, that is a user action vs a system action.
>> >> >>
>> >> >> This is just my $0.02. If others in the community have opinions,
>> >>please
>> >> >> share them.
>> >> >>
>> >> >> >
>> >> >> >On Tuesday, November 13, 2012, Franklin, Matthew B. wrote:
>> >> >> >
>> >> >> >> >-----Original Message-----
>> >> >> >> >From: Ryan Baxter [mailto:rbaxter85@apache.org <javascript:;>]
>> >> >> >> >Sent: Thursday, November 08, 2012 9:48 AM
>> >> >> >> >To: dev@rave.apache.org <javascript:;>
>> >> >> >> >Subject: Re: Problem with shindig api in rave
>> >> >> >> >
>> >> >> >> >In my opinion option 2 sounds the best and more consistent
>>with
>> >>what
>> >> >> >Rave
>> >> >> >> >does today. With that said I am not familiar with the code
>> >>either.
>> >> >> Can
>> >> >> >> >some of the other Rave experts weigh in here?
>> >> >> >>
>> >> >> >> IMO, trying to push everything to the page that could be used
>>via
>> >>EE
>> >> >> will
>> >> >> >> not scale well. I think having an endpoint configured that
>>can
>> >> >> generate a
>> >> >> >> security token and retrieve metadata for a gadget would be the
>> >> >> appropriate
>> >> >> >> model. I would however, suggest that the endpoint only return
>>a
>> >> >>valid
>> >> >> >> response for gadgets that are registered in the store.
>> >> >> >>
>> >> >> >> You can wire in a new controller in the rave-opensocial-client
>> >> >>project
>> >> >> by
>> >> >> >> annotating your controller class with @Controller and add a
>>method
>> >> >> >> annotated with @RequestMapping to specify the method and path.
>> I
>> >> >>would
>> >> >> >> also autowire in the existing security token service and just
>> >>create
>> >> >>a
>> >> >> >> "dummy" Region & RegionWidget for security token creation. Of
>> >> >>course,
>> >> >> >this
>> >> >> >> endpoint should only be accessible by an authenticated request,
>> >>but I
>> >> >> >> believe the current mappings in applicationContext-security.xml
>> >>will
>> >> >> handle
>> >> >> >> this.
>> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >On Tue, Nov 6, 2012 at 2:53 PM, Robert O'neill
>> >> >> ><roneill@us.ibm.com<javascript:;>>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >> I have dug a bit further into my issue and have found the
>> >> >>following.
>> >> >> >> >>
>> >> >> >> >> As it is currently implemented, the shindig api
>> >> >> >> >> gadgets.views.openEmbeddedExperience will not work in rave.
>> >> >> >> >>
>> >> >
>>
>>
Re: Problem with shindig api in rave
Posted by Ryan Baxter <rb...@gmail.com>.
This was my opinion as well, but after talking to Bob this afternoon it
sounded like he found a JIRA from Jesse which stated that Rave container
should not be making authenticated requests to the Shindig server, which
would be needed to return the security token in the metadata request. I
don't have the JIRA handy now but I will connect with Bob tomorrow and
forward that on.
On Mon, Nov 19, 2012 at 6:04 PM, Franklin, Matthew B.
<mf...@mitre.org>wrote:
> On 11/19/12 5:56 PM, "Ryan Baxter" <rb...@gmail.com> wrote:
>
> >So you want the security token returned with the metadata like Shindig
> >does
> >by default?
>
> IMO, that makes the most sense. Since Rave knows who the owner & viewer
> are, it needs to encrypt the token. Since common container will need both
> the metadata and the token and Rave already has a gadget metadata
> repository, returning both seems to me like the best way forward, but that
> is just my $0.02.
>
> >
> >On Monday, November 19, 2012, Franklin, Matthew B. wrote:
> >
> >> On 11/19/12 3:18 PM, "Ryan Baxter" <rbaxter85@apache.org<javascript:;>>
> >> wrote:
> >>
> >> >Matt are you proposing that potentially 2 requests be made when
> >>rendering
> >> >an embedded experience gadget? One to get the metadata and then one to
> >> >get
> >> >a security token?
> >>
> >> No, I would imagine that the controller would fetch and return metadata
> >> for the gadget as well.
> >>
> >> >
> >> >
> >> >On Wed, Nov 14, 2012 at 7:11 AM, Franklin, Matthew B.
> >> ><mf...@mitre.org>wrote:
> >> >
> >> >> >-----Original Message-----
> >> >> >From: Ryan Baxter [mailto:rbaxter85@gmail.com]
> >> >> >Sent: Wednesday, November 14, 2012 6:15 AM
> >> >> >To: dev@rave.apache.org
> >> >> >Subject: Re: Problem with shindig api in rave
> >> >> >
> >> >> >Matt I certainly trust your direction here since I am more of an
> >> >>observer
> >> >> >when it comes to this project, but shouldn't Rave be able to handle
> >> >>Option
> >> >> >2?
> >> >>
> >> >> The way I was looking at it, you can't know which embedded
> >>experiences
> >> >> will appear in an activity stream, so you would have to have all
> >> >> pre-registered gadgets capable of being rendered as EE on the page
> >>with
> >> >> valid security tokens. Adding all the metadata and tokens for this
> >>case
> >> >> seems inefficient, especially if there are a bunch of gadgets in the
> >> >>store.
> >> >>
> >> >> >What if today I had a bunch of widgets on a page wouldn't that be
> >> >> >essentially the same thing?
> >> >>
> >> >> You *could* add all the widgets in the store to your page as many
> >>times
> >> >>as
> >> >> you would like, but in practice I don't imagine this would be common.
> >> >> Either way, that is a user action vs a system action.
> >> >>
> >> >> This is just my $0.02. If others in the community have opinions,
> >>please
> >> >> share them.
> >> >>
> >> >> >
> >> >> >On Tuesday, November 13, 2012, Franklin, Matthew B. wrote:
> >> >> >
> >> >> >> >-----Original Message-----
> >> >> >> >From: Ryan Baxter [mailto:rbaxter85@apache.org <javascript:;>]
> >> >> >> >Sent: Thursday, November 08, 2012 9:48 AM
> >> >> >> >To: dev@rave.apache.org <javascript:;>
> >> >> >> >Subject: Re: Problem with shindig api in rave
> >> >> >> >
> >> >> >> >In my opinion option 2 sounds the best and more consistent with
> >>what
> >> >> >Rave
> >> >> >> >does today. With that said I am not familiar with the code
> >>either.
> >> >> Can
> >> >> >> >some of the other Rave experts weigh in here?
> >> >> >>
> >> >> >> IMO, trying to push everything to the page that could be used via
> >>EE
> >> >> will
> >> >> >> not scale well. I think having an endpoint configured that can
> >> >> generate a
> >> >> >> security token and retrieve metadata for a gadget would be the
> >> >> appropriate
> >> >> >> model. I would however, suggest that the endpoint only return a
> >> >>valid
> >> >> >> response for gadgets that are registered in the store.
> >> >> >>
> >> >> >> You can wire in a new controller in the rave-opensocial-client
> >> >>project
> >> >> by
> >> >> >> annotating your controller class with @Controller and add a method
> >> >> >> annotated with @RequestMapping to specify the method and path. I
> >> >>would
> >> >> >> also autowire in the existing security token service and just
> >>create
> >> >>a
> >> >> >> "dummy" Region & RegionWidget for security token creation. Of
> >> >>course,
> >> >> >this
> >> >> >> endpoint should only be accessible by an authenticated request,
> >>but I
> >> >> >> believe the current mappings in applicationContext-security.xml
> >>will
> >> >> handle
> >> >> >> this.
> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> >On Tue, Nov 6, 2012 at 2:53 PM, Robert O'neill
> >> >> ><roneill@us.ibm.com<javascript:;>>
> >> >> >> wrote:
> >> >> >> >
> >> >> >> >> I have dug a bit further into my issue and have found the
> >> >>following.
> >> >> >> >>
> >> >> >> >> As it is currently implemented, the shindig api
> >> >> >> >> gadgets.views.openEmbeddedExperience will not work in rave.
> >> >> >> >>
> >> >
>
>
Re: Problem with shindig api in rave
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 11/19/12 5:56 PM, "Ryan Baxter" <rb...@gmail.com> wrote:
>So you want the security token returned with the metadata like Shindig
>does
>by default?
IMO, that makes the most sense. Since Rave knows who the owner & viewer
are, it needs to encrypt the token. Since common container will need both
the metadata and the token and Rave already has a gadget metadata
repository, returning both seems to me like the best way forward, but that
is just my $0.02.
>
>On Monday, November 19, 2012, Franklin, Matthew B. wrote:
>
>> On 11/19/12 3:18 PM, "Ryan Baxter" <rbaxter85@apache.org <javascript:;>>
>> wrote:
>>
>> >Matt are you proposing that potentially 2 requests be made when
>>rendering
>> >an embedded experience gadget? One to get the metadata and then one to
>> >get
>> >a security token?
>>
>> No, I would imagine that the controller would fetch and return metadata
>> for the gadget as well.
>>
>> >
>> >
>> >On Wed, Nov 14, 2012 at 7:11 AM, Franklin, Matthew B.
>> ><mf...@mitre.org>wrote:
>> >
>> >> >-----Original Message-----
>> >> >From: Ryan Baxter [mailto:rbaxter85@gmail.com]
>> >> >Sent: Wednesday, November 14, 2012 6:15 AM
>> >> >To: dev@rave.apache.org
>> >> >Subject: Re: Problem with shindig api in rave
>> >> >
>> >> >Matt I certainly trust your direction here since I am more of an
>> >>observer
>> >> >when it comes to this project, but shouldn't Rave be able to handle
>> >>Option
>> >> >2?
>> >>
>> >> The way I was looking at it, you can't know which embedded
>>experiences
>> >> will appear in an activity stream, so you would have to have all
>> >> pre-registered gadgets capable of being rendered as EE on the page
>>with
>> >> valid security tokens. Adding all the metadata and tokens for this
>>case
>> >> seems inefficient, especially if there are a bunch of gadgets in the
>> >>store.
>> >>
>> >> >What if today I had a bunch of widgets on a page wouldn't that be
>> >> >essentially the same thing?
>> >>
>> >> You *could* add all the widgets in the store to your page as many
>>times
>> >>as
>> >> you would like, but in practice I don't imagine this would be common.
>> >> Either way, that is a user action vs a system action.
>> >>
>> >> This is just my $0.02. If others in the community have opinions,
>>please
>> >> share them.
>> >>
>> >> >
>> >> >On Tuesday, November 13, 2012, Franklin, Matthew B. wrote:
>> >> >
>> >> >> >-----Original Message-----
>> >> >> >From: Ryan Baxter [mailto:rbaxter85@apache.org <javascript:;>]
>> >> >> >Sent: Thursday, November 08, 2012 9:48 AM
>> >> >> >To: dev@rave.apache.org <javascript:;>
>> >> >> >Subject: Re: Problem with shindig api in rave
>> >> >> >
>> >> >> >In my opinion option 2 sounds the best and more consistent with
>>what
>> >> >Rave
>> >> >> >does today. With that said I am not familiar with the code
>>either.
>> >> Can
>> >> >> >some of the other Rave experts weigh in here?
>> >> >>
>> >> >> IMO, trying to push everything to the page that could be used via
>>EE
>> >> will
>> >> >> not scale well. I think having an endpoint configured that can
>> >> generate a
>> >> >> security token and retrieve metadata for a gadget would be the
>> >> appropriate
>> >> >> model. I would however, suggest that the endpoint only return a
>> >>valid
>> >> >> response for gadgets that are registered in the store.
>> >> >>
>> >> >> You can wire in a new controller in the rave-opensocial-client
>> >>project
>> >> by
>> >> >> annotating your controller class with @Controller and add a method
>> >> >> annotated with @RequestMapping to specify the method and path. I
>> >>would
>> >> >> also autowire in the existing security token service and just
>>create
>> >>a
>> >> >> "dummy" Region & RegionWidget for security token creation. Of
>> >>course,
>> >> >this
>> >> >> endpoint should only be accessible by an authenticated request,
>>but I
>> >> >> believe the current mappings in applicationContext-security.xml
>>will
>> >> handle
>> >> >> this.
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> >On Tue, Nov 6, 2012 at 2:53 PM, Robert O'neill
>> >> ><roneill@us.ibm.com<javascript:;>>
>> >> >> wrote:
>> >> >> >
>> >> >> >> I have dug a bit further into my issue and have found the
>> >>following.
>> >> >> >>
>> >> >> >> As it is currently implemented, the shindig api
>> >> >> >> gadgets.views.openEmbeddedExperience will not work in rave.
>> >> >> >>
>> >
Re: Problem with shindig api in rave
Posted by Ryan Baxter <rb...@gmail.com>.
So you want the security token returned with the metadata like Shindig does
by default?
On Monday, November 19, 2012, Franklin, Matthew B. wrote:
> On 11/19/12 3:18 PM, "Ryan Baxter" <rbaxter85@apache.org <javascript:;>>
> wrote:
>
> >Matt are you proposing that potentially 2 requests be made when rendering
> >an embedded experience gadget? One to get the metadata and then one to
> >get
> >a security token?
>
> No, I would imagine that the controller would fetch and return metadata
> for the gadget as well.
>
> >
> >
> >On Wed, Nov 14, 2012 at 7:11 AM, Franklin, Matthew B.
> ><mf...@mitre.org>wrote:
> >
> >> >-----Original Message-----
> >> >From: Ryan Baxter [mailto:rbaxter85@gmail.com]
> >> >Sent: Wednesday, November 14, 2012 6:15 AM
> >> >To: dev@rave.apache.org
> >> >Subject: Re: Problem with shindig api in rave
> >> >
> >> >Matt I certainly trust your direction here since I am more of an
> >>observer
> >> >when it comes to this project, but shouldn't Rave be able to handle
> >>Option
> >> >2?
> >>
> >> The way I was looking at it, you can't know which embedded experiences
> >> will appear in an activity stream, so you would have to have all
> >> pre-registered gadgets capable of being rendered as EE on the page with
> >> valid security tokens. Adding all the metadata and tokens for this case
> >> seems inefficient, especially if there are a bunch of gadgets in the
> >>store.
> >>
> >> >What if today I had a bunch of widgets on a page wouldn't that be
> >> >essentially the same thing?
> >>
> >> You *could* add all the widgets in the store to your page as many times
> >>as
> >> you would like, but in practice I don't imagine this would be common.
> >> Either way, that is a user action vs a system action.
> >>
> >> This is just my $0.02. If others in the community have opinions, please
> >> share them.
> >>
> >> >
> >> >On Tuesday, November 13, 2012, Franklin, Matthew B. wrote:
> >> >
> >> >> >-----Original Message-----
> >> >> >From: Ryan Baxter [mailto:rbaxter85@apache.org <javascript:;>]
> >> >> >Sent: Thursday, November 08, 2012 9:48 AM
> >> >> >To: dev@rave.apache.org <javascript:;>
> >> >> >Subject: Re: Problem with shindig api in rave
> >> >> >
> >> >> >In my opinion option 2 sounds the best and more consistent with what
> >> >Rave
> >> >> >does today. With that said I am not familiar with the code either.
> >> Can
> >> >> >some of the other Rave experts weigh in here?
> >> >>
> >> >> IMO, trying to push everything to the page that could be used via EE
> >> will
> >> >> not scale well. I think having an endpoint configured that can
> >> generate a
> >> >> security token and retrieve metadata for a gadget would be the
> >> appropriate
> >> >> model. I would however, suggest that the endpoint only return a
> >>valid
> >> >> response for gadgets that are registered in the store.
> >> >>
> >> >> You can wire in a new controller in the rave-opensocial-client
> >>project
> >> by
> >> >> annotating your controller class with @Controller and add a method
> >> >> annotated with @RequestMapping to specify the method and path. I
> >>would
> >> >> also autowire in the existing security token service and just create
> >>a
> >> >> "dummy" Region & RegionWidget for security token creation. Of
> >>course,
> >> >this
> >> >> endpoint should only be accessible by an authenticated request, but I
> >> >> believe the current mappings in applicationContext-security.xml will
> >> handle
> >> >> this.
> >> >>
> >> >> >
> >> >> >
> >> >> >On Tue, Nov 6, 2012 at 2:53 PM, Robert O'neill
> >> ><roneill@us.ibm.com<javascript:;>>
> >> >> wrote:
> >> >> >
> >> >> >> I have dug a bit further into my issue and have found the
> >>following.
> >> >> >>
> >> >> >> As it is currently implemented, the shindig api
> >> >> >> gadgets.views.openEmbeddedExperience will not work in rave.
> >> >> >>
> >
Re: Problem with shindig api in rave
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 11/19/12 3:18 PM, "Ryan Baxter" <rb...@apache.org> wrote:
>Matt are you proposing that potentially 2 requests be made when rendering
>an embedded experience gadget? One to get the metadata and then one to
>get
>a security token?
No, I would imagine that the controller would fetch and return metadata
for the gadget as well.
>
>
>On Wed, Nov 14, 2012 at 7:11 AM, Franklin, Matthew B.
><mf...@mitre.org>wrote:
>
>> >-----Original Message-----
>> >From: Ryan Baxter [mailto:rbaxter85@gmail.com]
>> >Sent: Wednesday, November 14, 2012 6:15 AM
>> >To: dev@rave.apache.org
>> >Subject: Re: Problem with shindig api in rave
>> >
>> >Matt I certainly trust your direction here since I am more of an
>>observer
>> >when it comes to this project, but shouldn't Rave be able to handle
>>Option
>> >2?
>>
>> The way I was looking at it, you can't know which embedded experiences
>> will appear in an activity stream, so you would have to have all
>> pre-registered gadgets capable of being rendered as EE on the page with
>> valid security tokens. Adding all the metadata and tokens for this case
>> seems inefficient, especially if there are a bunch of gadgets in the
>>store.
>>
>> >What if today I had a bunch of widgets on a page wouldn't that be
>> >essentially the same thing?
>>
>> You *could* add all the widgets in the store to your page as many times
>>as
>> you would like, but in practice I don't imagine this would be common.
>> Either way, that is a user action vs a system action.
>>
>> This is just my $0.02. If others in the community have opinions, please
>> share them.
>>
>> >
>> >On Tuesday, November 13, 2012, Franklin, Matthew B. wrote:
>> >
>> >> >-----Original Message-----
>> >> >From: Ryan Baxter [mailto:rbaxter85@apache.org <javascript:;>]
>> >> >Sent: Thursday, November 08, 2012 9:48 AM
>> >> >To: dev@rave.apache.org <javascript:;>
>> >> >Subject: Re: Problem with shindig api in rave
>> >> >
>> >> >In my opinion option 2 sounds the best and more consistent with what
>> >Rave
>> >> >does today. With that said I am not familiar with the code either.
>> Can
>> >> >some of the other Rave experts weigh in here?
>> >>
>> >> IMO, trying to push everything to the page that could be used via EE
>> will
>> >> not scale well. I think having an endpoint configured that can
>> generate a
>> >> security token and retrieve metadata for a gadget would be the
>> appropriate
>> >> model. I would however, suggest that the endpoint only return a
>>valid
>> >> response for gadgets that are registered in the store.
>> >>
>> >> You can wire in a new controller in the rave-opensocial-client
>>project
>> by
>> >> annotating your controller class with @Controller and add a method
>> >> annotated with @RequestMapping to specify the method and path. I
>>would
>> >> also autowire in the existing security token service and just create
>>a
>> >> "dummy" Region & RegionWidget for security token creation. Of
>>course,
>> >this
>> >> endpoint should only be accessible by an authenticated request, but I
>> >> believe the current mappings in applicationContext-security.xml will
>> handle
>> >> this.
>> >>
>> >> >
>> >> >
>> >> >On Tue, Nov 6, 2012 at 2:53 PM, Robert O'neill
>> ><roneill@us.ibm.com<javascript:;>>
>> >> wrote:
>> >> >
>> >> >> I have dug a bit further into my issue and have found the
>>following.
>> >> >>
>> >> >> As it is currently implemented, the shindig api
>> >> >> gadgets.views.openEmbeddedExperience will not work in rave.
>> >> >>
>> >> >> The api is designed to allow a gadget to open an arbitrary
>>embedded
>> >> >> experience gadget within the container.
>> >> >>
>> >> >> If I use the api to open an embedded experience from within a
>>gadget,
>> >> >> I get the following error:
>> >> >>
>> >> >> HTTP Status 401 - Malformed security token %st%Invalid security
>>token
>> >> >%st%
>> >> >>
>> >> >> The way that rave handles security tokens is causing this issue.
>>When
>> >> >> a rave page is rendered, any gadgets that are part of the page are
>> >> >> registered by statically injecting a script tag on the server side
>> >> >> into the page markup.
>> >> >>
>> >> >> The injected script has the following structure:
>> >> >>
>> >> >> rave.registerWidget(..., {
>> >> >> type: '...',
>> >> >> regionWidgetId: ...,
>> >> >> widgetUrl: '...',
>> >> >> securityToken: '...',
>> >> >> metadata: {...}
>> >> >> });
>> >> >>
>> >> >> This is the only mechanism, to my knowledge, of retrieving a
>>security
>> >> >> token for the gadget. Any gadget that is not initially part of the
>> >> >> page, at render time, will not have a security token.
>> >> >>
>> >> >> I have several proposals for dealing with this problem.
>> >> >>
>> >> >> 1.) Create an endpoint (or use an existing one if it exists) to
>> >> >> retrieve a security token for a gadget. When the
>> >> >> gadgets.views.openEmbeddedExperience api is called, the rave
>> >container
>> >> >> can retrieve a security token dynamically from this endpoint for a
>> given
>> >> >> gadget.
>> >> >>
>> >> >> Advantages:
>> >> >> - Client-side changes would be minimal
>> >> >> - Would not break existing functionality
>> >> >>
>> >> >> Disadvantages:
>> >> >> - Duplication of code of the server-side. The security
>> >> >> token code is not designed to handle creating a security token
>>for
>> a
>> >> >> gadget that is not within a region.
>> >> >> - A new servlet would have to be created for a very specific use
>> case.
>> >> >> - Would defeat the purpose of a having a store of trusted gadgets.
>> Any
>> >> >> third party gadget could request a security token and render
>> >> >>
>> >> >> 2.) Have any gadgets that could potentially be rendered through
>>the
>> >> >> gadgets.views.openEmbeddedExperience api be registered on page
>> >> >> load. These gadgets would be locked, collapsed, and have their
>>chrome
>> >> >> hidden. The container would have security token information about
>>the
>> >> >> gadget but the gadget would not render on the page. This would
>> require
>> >> >> database entries for each widget that could potentially be
>>rendered
>> on
>> >> >> the page.
>> >> >> At the moment, there is no ui for creating this.
>> >> >>
>> >> >> Advantages:
>> >> >> - No major code changes
>> >> >> - Uses existing functionality
>> >> >>
>> >> >> Disadvantages:
>> >> >> - Potentially inefficient to fetch the metadata for gadgets that
>>will
>> >> >> never render.
>> >> >> - UI would have to be created to configure this.
>> >> >>
>> >> >> Is there any other way to get this api to work that I am
>>overlooking
>> >> >> If not, I would like to hear what the community thinks about
>> solutions 1
>> >> >> and 2.
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> Robert O'Neill
>> >> >>
>> >> >> [image: Inactive hide details for Robert O'neill---11/01/2012
>> 06:14:42
>> >> >> PM---I found an issue using the following shindig api in rave:
>> g]Robert
>> >> >> O'neill---11/01/2012 06:14:42 PM---I found an issue using the
>> following
>> >> >> shindig api in rave: gadgets.views.openEmbeddedExperience(resul
>> >> >>
>> >> >> From: Robert O'neill/Boston/IBM@IBMUS
>> >> >> To: "Rave Dev" <dev@rave.apache.org <javascript:;>>,
>> >> >> Date: 11/01/2012 06:14 PM
>> >> >> Subject: Problem with shindig api in rave
>> >> >> ------------------------------
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> I found an issue using the following shindig api in rave:
>> >> >>
>> >> >> gadgets.views.openEmbeddedExperience(resultCallback,
>> >navigateCallback,
>> >> >> dataModel, opt_params);
>> >> >>
>> >> >> I have a gadget on my rave dashboard. From within this gadget, I
>>call
>> >> >> gadgets.views.openEmbeddedExperience to open a new gadget in a
>> >modal
>> >> >> dialog.
>> >> >>
>> >> >> When the modal dialog appears, I get the error:
>> >> >>
>> >> >> HTTP Status 401 - Malformed security token %st%Invalid security
>>token
>> >> >%st%
>> >> >>
>> >> >> My understanding of the issue is that the metadata for this
>>gadget is
>> >> >> not preloaded when this api call is made. Instead, gadget
>>metadata is
>> >> >> fetched once on page load for gadgets that are embedded in the
>> >> >> page. For gadgets that are dynamically added, there will be no
>> >> >> metadata and therefore no security token.
>> >> >>
>> >> >> The only way to get around the issue at the moment is to add the
>> >> >> target gadget to the page. This properly preloads the gadget
>>metadata
>> >> >> and retrieves the security token and the call to
>> >> >> gadgets.views.openEmbeddedExperience works as expected. For my
>> >use
>> >> >> case, this workaround will not suffice.
>> >> >>
>> >> >> I am willing to dig into this issue and provide a fix.
>> >> >>
>> >> >> Is there a specific place within the code where I should look
>>first?
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> Robert O'Neill
>> >> >>
>> >> >>
>> >>
>>
Re: Problem with shindig api in rave
Posted by Ryan Baxter <rb...@apache.org>.
Matt are you proposing that potentially 2 requests be made when rendering
an embedded experience gadget? One to get the metadata and then one to get
a security token?
On Wed, Nov 14, 2012 at 7:11 AM, Franklin, Matthew B.
<mf...@mitre.org>wrote:
> >-----Original Message-----
> >From: Ryan Baxter [mailto:rbaxter85@gmail.com]
> >Sent: Wednesday, November 14, 2012 6:15 AM
> >To: dev@rave.apache.org
> >Subject: Re: Problem with shindig api in rave
> >
> >Matt I certainly trust your direction here since I am more of an observer
> >when it comes to this project, but shouldn't Rave be able to handle Option
> >2?
>
> The way I was looking at it, you can't know which embedded experiences
> will appear in an activity stream, so you would have to have all
> pre-registered gadgets capable of being rendered as EE on the page with
> valid security tokens. Adding all the metadata and tokens for this case
> seems inefficient, especially if there are a bunch of gadgets in the store.
>
> >What if today I had a bunch of widgets on a page wouldn't that be
> >essentially the same thing?
>
> You *could* add all the widgets in the store to your page as many times as
> you would like, but in practice I don't imagine this would be common.
> Either way, that is a user action vs a system action.
>
> This is just my $0.02. If others in the community have opinions, please
> share them.
>
> >
> >On Tuesday, November 13, 2012, Franklin, Matthew B. wrote:
> >
> >> >-----Original Message-----
> >> >From: Ryan Baxter [mailto:rbaxter85@apache.org <javascript:;>]
> >> >Sent: Thursday, November 08, 2012 9:48 AM
> >> >To: dev@rave.apache.org <javascript:;>
> >> >Subject: Re: Problem with shindig api in rave
> >> >
> >> >In my opinion option 2 sounds the best and more consistent with what
> >Rave
> >> >does today. With that said I am not familiar with the code either.
> Can
> >> >some of the other Rave experts weigh in here?
> >>
> >> IMO, trying to push everything to the page that could be used via EE
> will
> >> not scale well. I think having an endpoint configured that can
> generate a
> >> security token and retrieve metadata for a gadget would be the
> appropriate
> >> model. I would however, suggest that the endpoint only return a valid
> >> response for gadgets that are registered in the store.
> >>
> >> You can wire in a new controller in the rave-opensocial-client project
> by
> >> annotating your controller class with @Controller and add a method
> >> annotated with @RequestMapping to specify the method and path. I would
> >> also autowire in the existing security token service and just create a
> >> "dummy" Region & RegionWidget for security token creation. Of course,
> >this
> >> endpoint should only be accessible by an authenticated request, but I
> >> believe the current mappings in applicationContext-security.xml will
> handle
> >> this.
> >>
> >> >
> >> >
> >> >On Tue, Nov 6, 2012 at 2:53 PM, Robert O'neill
> ><roneill@us.ibm.com<javascript:;>>
> >> wrote:
> >> >
> >> >> I have dug a bit further into my issue and have found the following.
> >> >>
> >> >> As it is currently implemented, the shindig api
> >> >> gadgets.views.openEmbeddedExperience will not work in rave.
> >> >>
> >> >> The api is designed to allow a gadget to open an arbitrary embedded
> >> >> experience gadget within the container.
> >> >>
> >> >> If I use the api to open an embedded experience from within a gadget,
> >> >> I get the following error:
> >> >>
> >> >> HTTP Status 401 - Malformed security token %st%Invalid security token
> >> >%st%
> >> >>
> >> >> The way that rave handles security tokens is causing this issue. When
> >> >> a rave page is rendered, any gadgets that are part of the page are
> >> >> registered by statically injecting a script tag on the server side
> >> >> into the page markup.
> >> >>
> >> >> The injected script has the following structure:
> >> >>
> >> >> rave.registerWidget(..., {
> >> >> type: '...',
> >> >> regionWidgetId: ...,
> >> >> widgetUrl: '...',
> >> >> securityToken: '...',
> >> >> metadata: {...}
> >> >> });
> >> >>
> >> >> This is the only mechanism, to my knowledge, of retrieving a security
> >> >> token for the gadget. Any gadget that is not initially part of the
> >> >> page, at render time, will not have a security token.
> >> >>
> >> >> I have several proposals for dealing with this problem.
> >> >>
> >> >> 1.) Create an endpoint (or use an existing one if it exists) to
> >> >> retrieve a security token for a gadget. When the
> >> >> gadgets.views.openEmbeddedExperience api is called, the rave
> >container
> >> >> can retrieve a security token dynamically from this endpoint for a
> given
> >> >> gadget.
> >> >>
> >> >> Advantages:
> >> >> - Client-side changes would be minimal
> >> >> - Would not break existing functionality
> >> >>
> >> >> Disadvantages:
> >> >> - Duplication of code of the server-side. The security
> >> >> token code is not designed to handle creating a security token for
> a
> >> >> gadget that is not within a region.
> >> >> - A new servlet would have to be created for a very specific use
> case.
> >> >> - Would defeat the purpose of a having a store of trusted gadgets.
> Any
> >> >> third party gadget could request a security token and render
> >> >>
> >> >> 2.) Have any gadgets that could potentially be rendered through the
> >> >> gadgets.views.openEmbeddedExperience api be registered on page
> >> >> load. These gadgets would be locked, collapsed, and have their chrome
> >> >> hidden. The container would have security token information about the
> >> >> gadget but the gadget would not render on the page. This would
> require
> >> >> database entries for each widget that could potentially be rendered
> on
> >> >> the page.
> >> >> At the moment, there is no ui for creating this.
> >> >>
> >> >> Advantages:
> >> >> - No major code changes
> >> >> - Uses existing functionality
> >> >>
> >> >> Disadvantages:
> >> >> - Potentially inefficient to fetch the metadata for gadgets that will
> >> >> never render.
> >> >> - UI would have to be created to configure this.
> >> >>
> >> >> Is there any other way to get this api to work that I am overlooking
> >> >> If not, I would like to hear what the community thinks about
> solutions 1
> >> >> and 2.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Robert O'Neill
> >> >>
> >> >> [image: Inactive hide details for Robert O'neill---11/01/2012
> 06:14:42
> >> >> PM---I found an issue using the following shindig api in rave:
> g]Robert
> >> >> O'neill---11/01/2012 06:14:42 PM---I found an issue using the
> following
> >> >> shindig api in rave: gadgets.views.openEmbeddedExperience(resul
> >> >>
> >> >> From: Robert O'neill/Boston/IBM@IBMUS
> >> >> To: "Rave Dev" <dev@rave.apache.org <javascript:;>>,
> >> >> Date: 11/01/2012 06:14 PM
> >> >> Subject: Problem with shindig api in rave
> >> >> ------------------------------
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> I found an issue using the following shindig api in rave:
> >> >>
> >> >> gadgets.views.openEmbeddedExperience(resultCallback,
> >navigateCallback,
> >> >> dataModel, opt_params);
> >> >>
> >> >> I have a gadget on my rave dashboard. From within this gadget, I call
> >> >> gadgets.views.openEmbeddedExperience to open a new gadget in a
> >modal
> >> >> dialog.
> >> >>
> >> >> When the modal dialog appears, I get the error:
> >> >>
> >> >> HTTP Status 401 - Malformed security token %st%Invalid security token
> >> >%st%
> >> >>
> >> >> My understanding of the issue is that the metadata for this gadget is
> >> >> not preloaded when this api call is made. Instead, gadget metadata is
> >> >> fetched once on page load for gadgets that are embedded in the
> >> >> page. For gadgets that are dynamically added, there will be no
> >> >> metadata and therefore no security token.
> >> >>
> >> >> The only way to get around the issue at the moment is to add the
> >> >> target gadget to the page. This properly preloads the gadget metadata
> >> >> and retrieves the security token and the call to
> >> >> gadgets.views.openEmbeddedExperience works as expected. For my
> >use
> >> >> case, this workaround will not suffice.
> >> >>
> >> >> I am willing to dig into this issue and provide a fix.
> >> >>
> >> >> Is there a specific place within the code where I should look first?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Robert O'Neill
> >> >>
> >> >>
> >>
>
RE: Problem with shindig api in rave
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Ryan Baxter [mailto:rbaxter85@gmail.com]
>Sent: Wednesday, November 14, 2012 6:15 AM
>To: dev@rave.apache.org
>Subject: Re: Problem with shindig api in rave
>
>Matt I certainly trust your direction here since I am more of an observer
>when it comes to this project, but shouldn't Rave be able to handle Option
>2?
The way I was looking at it, you can't know which embedded experiences will appear in an activity stream, so you would have to have all pre-registered gadgets capable of being rendered as EE on the page with valid security tokens. Adding all the metadata and tokens for this case seems inefficient, especially if there are a bunch of gadgets in the store.
>What if today I had a bunch of widgets on a page wouldn't that be
>essentially the same thing?
You *could* add all the widgets in the store to your page as many times as you would like, but in practice I don't imagine this would be common. Either way, that is a user action vs a system action.
This is just my $0.02. If others in the community have opinions, please share them.
>
>On Tuesday, November 13, 2012, Franklin, Matthew B. wrote:
>
>> >-----Original Message-----
>> >From: Ryan Baxter [mailto:rbaxter85@apache.org <javascript:;>]
>> >Sent: Thursday, November 08, 2012 9:48 AM
>> >To: dev@rave.apache.org <javascript:;>
>> >Subject: Re: Problem with shindig api in rave
>> >
>> >In my opinion option 2 sounds the best and more consistent with what
>Rave
>> >does today. With that said I am not familiar with the code either. Can
>> >some of the other Rave experts weigh in here?
>>
>> IMO, trying to push everything to the page that could be used via EE will
>> not scale well. I think having an endpoint configured that can generate a
>> security token and retrieve metadata for a gadget would be the appropriate
>> model. I would however, suggest that the endpoint only return a valid
>> response for gadgets that are registered in the store.
>>
>> You can wire in a new controller in the rave-opensocial-client project by
>> annotating your controller class with @Controller and add a method
>> annotated with @RequestMapping to specify the method and path. I would
>> also autowire in the existing security token service and just create a
>> "dummy" Region & RegionWidget for security token creation. Of course,
>this
>> endpoint should only be accessible by an authenticated request, but I
>> believe the current mappings in applicationContext-security.xml will handle
>> this.
>>
>> >
>> >
>> >On Tue, Nov 6, 2012 at 2:53 PM, Robert O'neill
><roneill@us.ibm.com<javascript:;>>
>> wrote:
>> >
>> >> I have dug a bit further into my issue and have found the following.
>> >>
>> >> As it is currently implemented, the shindig api
>> >> gadgets.views.openEmbeddedExperience will not work in rave.
>> >>
>> >> The api is designed to allow a gadget to open an arbitrary embedded
>> >> experience gadget within the container.
>> >>
>> >> If I use the api to open an embedded experience from within a gadget,
>> >> I get the following error:
>> >>
>> >> HTTP Status 401 - Malformed security token %st%Invalid security token
>> >%st%
>> >>
>> >> The way that rave handles security tokens is causing this issue. When
>> >> a rave page is rendered, any gadgets that are part of the page are
>> >> registered by statically injecting a script tag on the server side
>> >> into the page markup.
>> >>
>> >> The injected script has the following structure:
>> >>
>> >> rave.registerWidget(..., {
>> >> type: '...',
>> >> regionWidgetId: ...,
>> >> widgetUrl: '...',
>> >> securityToken: '...',
>> >> metadata: {...}
>> >> });
>> >>
>> >> This is the only mechanism, to my knowledge, of retrieving a security
>> >> token for the gadget. Any gadget that is not initially part of the
>> >> page, at render time, will not have a security token.
>> >>
>> >> I have several proposals for dealing with this problem.
>> >>
>> >> 1.) Create an endpoint (or use an existing one if it exists) to
>> >> retrieve a security token for a gadget. When the
>> >> gadgets.views.openEmbeddedExperience api is called, the rave
>container
>> >> can retrieve a security token dynamically from this endpoint for a given
>> >> gadget.
>> >>
>> >> Advantages:
>> >> - Client-side changes would be minimal
>> >> - Would not break existing functionality
>> >>
>> >> Disadvantages:
>> >> - Duplication of code of the server-side. The security
>> >> token code is not designed to handle creating a security token for a
>> >> gadget that is not within a region.
>> >> - A new servlet would have to be created for a very specific use case.
>> >> - Would defeat the purpose of a having a store of trusted gadgets. Any
>> >> third party gadget could request a security token and render
>> >>
>> >> 2.) Have any gadgets that could potentially be rendered through the
>> >> gadgets.views.openEmbeddedExperience api be registered on page
>> >> load. These gadgets would be locked, collapsed, and have their chrome
>> >> hidden. The container would have security token information about the
>> >> gadget but the gadget would not render on the page. This would require
>> >> database entries for each widget that could potentially be rendered on
>> >> the page.
>> >> At the moment, there is no ui for creating this.
>> >>
>> >> Advantages:
>> >> - No major code changes
>> >> - Uses existing functionality
>> >>
>> >> Disadvantages:
>> >> - Potentially inefficient to fetch the metadata for gadgets that will
>> >> never render.
>> >> - UI would have to be created to configure this.
>> >>
>> >> Is there any other way to get this api to work that I am overlooking
>> >> If not, I would like to hear what the community thinks about solutions 1
>> >> and 2.
>> >>
>> >> Thanks,
>> >>
>> >> Robert O'Neill
>> >>
>> >> [image: Inactive hide details for Robert O'neill---11/01/2012 06:14:42
>> >> PM---I found an issue using the following shindig api in rave: g]Robert
>> >> O'neill---11/01/2012 06:14:42 PM---I found an issue using the following
>> >> shindig api in rave: gadgets.views.openEmbeddedExperience(resul
>> >>
>> >> From: Robert O'neill/Boston/IBM@IBMUS
>> >> To: "Rave Dev" <dev@rave.apache.org <javascript:;>>,
>> >> Date: 11/01/2012 06:14 PM
>> >> Subject: Problem with shindig api in rave
>> >> ------------------------------
>> >>
>> >>
>> >>
>> >>
>> >> I found an issue using the following shindig api in rave:
>> >>
>> >> gadgets.views.openEmbeddedExperience(resultCallback,
>navigateCallback,
>> >> dataModel, opt_params);
>> >>
>> >> I have a gadget on my rave dashboard. From within this gadget, I call
>> >> gadgets.views.openEmbeddedExperience to open a new gadget in a
>modal
>> >> dialog.
>> >>
>> >> When the modal dialog appears, I get the error:
>> >>
>> >> HTTP Status 401 - Malformed security token %st%Invalid security token
>> >%st%
>> >>
>> >> My understanding of the issue is that the metadata for this gadget is
>> >> not preloaded when this api call is made. Instead, gadget metadata is
>> >> fetched once on page load for gadgets that are embedded in the
>> >> page. For gadgets that are dynamically added, there will be no
>> >> metadata and therefore no security token.
>> >>
>> >> The only way to get around the issue at the moment is to add the
>> >> target gadget to the page. This properly preloads the gadget metadata
>> >> and retrieves the security token and the call to
>> >> gadgets.views.openEmbeddedExperience works as expected. For my
>use
>> >> case, this workaround will not suffice.
>> >>
>> >> I am willing to dig into this issue and provide a fix.
>> >>
>> >> Is there a specific place within the code where I should look first?
>> >>
>> >> Thanks,
>> >>
>> >> Robert O'Neill
>> >>
>> >>
>>
Re: Problem with shindig api in rave
Posted by Ryan Baxter <rb...@gmail.com>.
Matt I certainly trust your direction here since I am more of an observer
when it comes to this project, but shouldn't Rave be able to handle Option
2? What if today I had a bunch of widgets on a page wouldn't that be
essentially the same thing?
On Tuesday, November 13, 2012, Franklin, Matthew B. wrote:
> >-----Original Message-----
> >From: Ryan Baxter [mailto:rbaxter85@apache.org <javascript:;>]
> >Sent: Thursday, November 08, 2012 9:48 AM
> >To: dev@rave.apache.org <javascript:;>
> >Subject: Re: Problem with shindig api in rave
> >
> >In my opinion option 2 sounds the best and more consistent with what Rave
> >does today. With that said I am not familiar with the code either. Can
> >some of the other Rave experts weigh in here?
>
> IMO, trying to push everything to the page that could be used via EE will
> not scale well. I think having an endpoint configured that can generate a
> security token and retrieve metadata for a gadget would be the appropriate
> model. I would however, suggest that the endpoint only return a valid
> response for gadgets that are registered in the store.
>
> You can wire in a new controller in the rave-opensocial-client project by
> annotating your controller class with @Controller and add a method
> annotated with @RequestMapping to specify the method and path. I would
> also autowire in the existing security token service and just create a
> "dummy" Region & RegionWidget for security token creation. Of course, this
> endpoint should only be accessible by an authenticated request, but I
> believe the current mappings in applicationContext-security.xml will handle
> this.
>
> >
> >
> >On Tue, Nov 6, 2012 at 2:53 PM, Robert O'neill <roneill@us.ibm.com<javascript:;>>
> wrote:
> >
> >> I have dug a bit further into my issue and have found the following.
> >>
> >> As it is currently implemented, the shindig api
> >> gadgets.views.openEmbeddedExperience will not work in rave.
> >>
> >> The api is designed to allow a gadget to open an arbitrary embedded
> >> experience gadget within the container.
> >>
> >> If I use the api to open an embedded experience from within a gadget,
> >> I get the following error:
> >>
> >> HTTP Status 401 - Malformed security token %st%Invalid security token
> >%st%
> >>
> >> The way that rave handles security tokens is causing this issue. When
> >> a rave page is rendered, any gadgets that are part of the page are
> >> registered by statically injecting a script tag on the server side
> >> into the page markup.
> >>
> >> The injected script has the following structure:
> >>
> >> rave.registerWidget(..., {
> >> type: '...',
> >> regionWidgetId: ...,
> >> widgetUrl: '...',
> >> securityToken: '...',
> >> metadata: {...}
> >> });
> >>
> >> This is the only mechanism, to my knowledge, of retrieving a security
> >> token for the gadget. Any gadget that is not initially part of the
> >> page, at render time, will not have a security token.
> >>
> >> I have several proposals for dealing with this problem.
> >>
> >> 1.) Create an endpoint (or use an existing one if it exists) to
> >> retrieve a security token for a gadget. When the
> >> gadgets.views.openEmbeddedExperience api is called, the rave container
> >> can retrieve a security token dynamically from this endpoint for a given
> >> gadget.
> >>
> >> Advantages:
> >> - Client-side changes would be minimal
> >> - Would not break existing functionality
> >>
> >> Disadvantages:
> >> - Duplication of code of the server-side. The security
> >> token code is not designed to handle creating a security token for a
> >> gadget that is not within a region.
> >> - A new servlet would have to be created for a very specific use case.
> >> - Would defeat the purpose of a having a store of trusted gadgets. Any
> >> third party gadget could request a security token and render
> >>
> >> 2.) Have any gadgets that could potentially be rendered through the
> >> gadgets.views.openEmbeddedExperience api be registered on page
> >> load. These gadgets would be locked, collapsed, and have their chrome
> >> hidden. The container would have security token information about the
> >> gadget but the gadget would not render on the page. This would require
> >> database entries for each widget that could potentially be rendered on
> >> the page.
> >> At the moment, there is no ui for creating this.
> >>
> >> Advantages:
> >> - No major code changes
> >> - Uses existing functionality
> >>
> >> Disadvantages:
> >> - Potentially inefficient to fetch the metadata for gadgets that will
> >> never render.
> >> - UI would have to be created to configure this.
> >>
> >> Is there any other way to get this api to work that I am overlooking
> >> If not, I would like to hear what the community thinks about solutions 1
> >> and 2.
> >>
> >> Thanks,
> >>
> >> Robert O'Neill
> >>
> >> [image: Inactive hide details for Robert O'neill---11/01/2012 06:14:42
> >> PM---I found an issue using the following shindig api in rave: g]Robert
> >> O'neill---11/01/2012 06:14:42 PM---I found an issue using the following
> >> shindig api in rave: gadgets.views.openEmbeddedExperience(resul
> >>
> >> From: Robert O'neill/Boston/IBM@IBMUS
> >> To: "Rave Dev" <dev@rave.apache.org <javascript:;>>,
> >> Date: 11/01/2012 06:14 PM
> >> Subject: Problem with shindig api in rave
> >> ------------------------------
> >>
> >>
> >>
> >>
> >> I found an issue using the following shindig api in rave:
> >>
> >> gadgets.views.openEmbeddedExperience(resultCallback, navigateCallback,
> >> dataModel, opt_params);
> >>
> >> I have a gadget on my rave dashboard. From within this gadget, I call
> >> gadgets.views.openEmbeddedExperience to open a new gadget in a modal
> >> dialog.
> >>
> >> When the modal dialog appears, I get the error:
> >>
> >> HTTP Status 401 - Malformed security token %st%Invalid security token
> >%st%
> >>
> >> My understanding of the issue is that the metadata for this gadget is
> >> not preloaded when this api call is made. Instead, gadget metadata is
> >> fetched once on page load for gadgets that are embedded in the
> >> page. For gadgets that are dynamically added, there will be no
> >> metadata and therefore no security token.
> >>
> >> The only way to get around the issue at the moment is to add the
> >> target gadget to the page. This properly preloads the gadget metadata
> >> and retrieves the security token and the call to
> >> gadgets.views.openEmbeddedExperience works as expected. For my use
> >> case, this workaround will not suffice.
> >>
> >> I am willing to dig into this issue and provide a fix.
> >>
> >> Is there a specific place within the code where I should look first?
> >>
> >> Thanks,
> >>
> >> Robert O'Neill
> >>
> >>
>
RE: Problem with shindig api in rave
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Ryan Baxter [mailto:rbaxter85@apache.org]
>Sent: Thursday, November 08, 2012 9:48 AM
>To: dev@rave.apache.org
>Subject: Re: Problem with shindig api in rave
>
>In my opinion option 2 sounds the best and more consistent with what Rave
>does today. With that said I am not familiar with the code either. Can
>some of the other Rave experts weigh in here?
IMO, trying to push everything to the page that could be used via EE will not scale well. I think having an endpoint configured that can generate a security token and retrieve metadata for a gadget would be the appropriate model. I would however, suggest that the endpoint only return a valid response for gadgets that are registered in the store.
You can wire in a new controller in the rave-opensocial-client project by annotating your controller class with @Controller and add a method annotated with @RequestMapping to specify the method and path. I would also autowire in the existing security token service and just create a "dummy" Region & RegionWidget for security token creation. Of course, this endpoint should only be accessible by an authenticated request, but I believe the current mappings in applicationContext-security.xml will handle this.
>
>
>On Tue, Nov 6, 2012 at 2:53 PM, Robert O'neill <ro...@us.ibm.com> wrote:
>
>> I have dug a bit further into my issue and have found the following.
>>
>> As it is currently implemented, the shindig api
>> gadgets.views.openEmbeddedExperience will not work in rave.
>>
>> The api is designed to allow a gadget to open an arbitrary embedded
>> experience gadget within the container.
>>
>> If I use the api to open an embedded experience from within a gadget,
>> I get the following error:
>>
>> HTTP Status 401 - Malformed security token %st%Invalid security token
>%st%
>>
>> The way that rave handles security tokens is causing this issue. When
>> a rave page is rendered, any gadgets that are part of the page are
>> registered by statically injecting a script tag on the server side
>> into the page markup.
>>
>> The injected script has the following structure:
>>
>> rave.registerWidget(..., {
>> type: '...',
>> regionWidgetId: ...,
>> widgetUrl: '...',
>> securityToken: '...',
>> metadata: {...}
>> });
>>
>> This is the only mechanism, to my knowledge, of retrieving a security
>> token for the gadget. Any gadget that is not initially part of the
>> page, at render time, will not have a security token.
>>
>> I have several proposals for dealing with this problem.
>>
>> 1.) Create an endpoint (or use an existing one if it exists) to
>> retrieve a security token for a gadget. When the
>> gadgets.views.openEmbeddedExperience api is called, the rave container
>> can retrieve a security token dynamically from this endpoint for a given
>> gadget.
>>
>> Advantages:
>> - Client-side changes would be minimal
>> - Would not break existing functionality
>>
>> Disadvantages:
>> - Duplication of code of the server-side. The security
>> token code is not designed to handle creating a security token for a
>> gadget that is not within a region.
>> - A new servlet would have to be created for a very specific use case.
>> - Would defeat the purpose of a having a store of trusted gadgets. Any
>> third party gadget could request a security token and render
>>
>> 2.) Have any gadgets that could potentially be rendered through the
>> gadgets.views.openEmbeddedExperience api be registered on page
>> load. These gadgets would be locked, collapsed, and have their chrome
>> hidden. The container would have security token information about the
>> gadget but the gadget would not render on the page. This would require
>> database entries for each widget that could potentially be rendered on
>> the page.
>> At the moment, there is no ui for creating this.
>>
>> Advantages:
>> - No major code changes
>> - Uses existing functionality
>>
>> Disadvantages:
>> - Potentially inefficient to fetch the metadata for gadgets that will
>> never render.
>> - UI would have to be created to configure this.
>>
>> Is there any other way to get this api to work that I am overlooking
>> If not, I would like to hear what the community thinks about solutions 1
>> and 2.
>>
>> Thanks,
>>
>> Robert O'Neill
>>
>> [image: Inactive hide details for Robert O'neill---11/01/2012 06:14:42
>> PM---I found an issue using the following shindig api in rave: g]Robert
>> O'neill---11/01/2012 06:14:42 PM---I found an issue using the following
>> shindig api in rave: gadgets.views.openEmbeddedExperience(resul
>>
>> From: Robert O'neill/Boston/IBM@IBMUS
>> To: "Rave Dev" <de...@rave.apache.org>,
>> Date: 11/01/2012 06:14 PM
>> Subject: Problem with shindig api in rave
>> ------------------------------
>>
>>
>>
>>
>> I found an issue using the following shindig api in rave:
>>
>> gadgets.views.openEmbeddedExperience(resultCallback, navigateCallback,
>> dataModel, opt_params);
>>
>> I have a gadget on my rave dashboard. From within this gadget, I call
>> gadgets.views.openEmbeddedExperience to open a new gadget in a modal
>> dialog.
>>
>> When the modal dialog appears, I get the error:
>>
>> HTTP Status 401 - Malformed security token %st%Invalid security token
>%st%
>>
>> My understanding of the issue is that the metadata for this gadget is
>> not preloaded when this api call is made. Instead, gadget metadata is
>> fetched once on page load for gadgets that are embedded in the
>> page. For gadgets that are dynamically added, there will be no
>> metadata and therefore no security token.
>>
>> The only way to get around the issue at the moment is to add the
>> target gadget to the page. This properly preloads the gadget metadata
>> and retrieves the security token and the call to
>> gadgets.views.openEmbeddedExperience works as expected. For my use
>> case, this workaround will not suffice.
>>
>> I am willing to dig into this issue and provide a fix.
>>
>> Is there a specific place within the code where I should look first?
>>
>> Thanks,
>>
>> Robert O'Neill
>>
>>
Re: Problem with shindig api in rave
Posted by Ryan Baxter <rb...@apache.org>.
In my opinion option 2 sounds the best and more consistent with what Rave
does today. With that said I am not familiar with the code either. Can
some of the other Rave experts weigh in here?
On Tue, Nov 6, 2012 at 2:53 PM, Robert O'neill <ro...@us.ibm.com> wrote:
> I have dug a bit further into my issue and have found the following.
>
> As it is currently implemented, the shindig api
> gadgets.views.openEmbeddedExperience will not work in rave.
>
> The api is designed to allow a gadget to open an arbitrary embedded
> experience gadget within the container.
>
> If I use the api to open an embedded experience from within a gadget,
> I get the following error:
>
> HTTP Status 401 - Malformed security token %st%Invalid security token %st%
>
> The way that rave handles security tokens is causing this issue. When
> a rave page is rendered, any gadgets that are part of the page are
> registered by statically injecting a script tag on the server side
> into the page markup.
>
> The injected script has the following structure:
>
> rave.registerWidget(..., {
> type: '...',
> regionWidgetId: ...,
> widgetUrl: '...',
> securityToken: '...',
> metadata: {...}
> });
>
> This is the only mechanism, to my knowledge, of retrieving a security
> token for the gadget. Any gadget that is not initially part of the
> page, at render time, will not have a security token.
>
> I have several proposals for dealing with this problem.
>
> 1.) Create an endpoint (or use an existing one if it exists) to
> retrieve a security token for a gadget. When the
> gadgets.views.openEmbeddedExperience api is called, the rave container
> can retrieve a security token dynamically from this endpoint for a given
> gadget.
>
> Advantages:
> - Client-side changes would be minimal
> - Would not break existing functionality
>
> Disadvantages:
> - Duplication of code of the server-side. The security
> token code is not designed to handle creating a security token for a
> gadget that is not within a region.
> - A new servlet would have to be created for a very specific use case.
> - Would defeat the purpose of a having a store of trusted gadgets. Any
> third party gadget could request a security token and render
>
> 2.) Have any gadgets that could potentially be rendered through the
> gadgets.views.openEmbeddedExperience api be registered on page
> load. These gadgets would be locked, collapsed, and have their chrome
> hidden. The container would have security token information about the
> gadget but the gadget would not render on the page. This would require
> database entries for each widget that could potentially be rendered on
> the page.
> At the moment, there is no ui for creating this.
>
> Advantages:
> - No major code changes
> - Uses existing functionality
>
> Disadvantages:
> - Potentially inefficient to fetch the metadata for gadgets that will
> never render.
> - UI would have to be created to configure this.
>
> Is there any other way to get this api to work that I am overlooking
> If not, I would like to hear what the community thinks about solutions 1
> and 2.
>
> Thanks,
>
> Robert O'Neill
>
> [image: Inactive hide details for Robert O'neill---11/01/2012 06:14:42
> PM---I found an issue using the following shindig api in rave: g]Robert
> O'neill---11/01/2012 06:14:42 PM---I found an issue using the following
> shindig api in rave: gadgets.views.openEmbeddedExperience(resul
>
> From: Robert O'neill/Boston/IBM@IBMUS
> To: "Rave Dev" <de...@rave.apache.org>,
> Date: 11/01/2012 06:14 PM
> Subject: Problem with shindig api in rave
> ------------------------------
>
>
>
>
> I found an issue using the following shindig api in rave:
>
> gadgets.views.openEmbeddedExperience(resultCallback, navigateCallback,
> dataModel, opt_params);
>
> I have a gadget on my rave dashboard. From within this gadget, I call
> gadgets.views.openEmbeddedExperience to open a new gadget in a modal
> dialog.
>
> When the modal dialog appears, I get the error:
>
> HTTP Status 401 - Malformed security token %st%Invalid security token %st%
>
> My understanding of the issue is that the metadata for this gadget is
> not preloaded when this api call is made. Instead, gadget metadata is
> fetched once on page load for gadgets that are embedded in the
> page. For gadgets that are dynamically added, there will be no
> metadata and therefore no security token.
>
> The only way to get around the issue at the moment is to add the
> target gadget to the page. This properly preloads the gadget metadata
> and retrieves the security token and the call to
> gadgets.views.openEmbeddedExperience works as expected. For my use
> case, this workaround will not suffice.
>
> I am willing to dig into this issue and provide a fix.
>
> Is there a specific place within the code where I should look first?
>
> Thanks,
>
> Robert O'Neill
>
>
Re: Problem with shindig api in rave
Posted by Robert O'neill <ro...@us.ibm.com>.
I have dug a bit further into my issue and have found the following.
As it is currently implemented, the shindig api
gadgets.views.openEmbeddedExperience will not work in rave.
The api is designed to allow a gadget to open an arbitrary embedded
experience gadget within the container.
If I use the api to open an embedded experience from within a gadget,
I get the following error:
HTTP Status 401 - Malformed security token %st%Invalid security token %st%
The way that rave handles security tokens is causing this issue. When
a rave page is rendered, any gadgets that are part of the page are
registered by statically injecting a script tag on the server side
into the page markup.
The injected script has the following structure:
rave.registerWidget(..., {
type: '...',
regionWidgetId: ...,
widgetUrl: '...',
securityToken: '...',
metadata: {...}
});
This is the only mechanism, to my knowledge, of retrieving a security
token for the gadget. Any gadget that is not initially part of the
page, at render time, will not have a security token.
I have several proposals for dealing with this problem.
1.) Create an endpoint (or use an existing one if it exists) to
retrieve a security token for a gadget. When the
gadgets.views.openEmbeddedExperience api is called, the rave container
can retrieve a security token dynamically from this endpoint for a given
gadget.
Advantages:
- Client-side changes would be minimal
- Would not break existing functionality
Disadvantages:
- Duplication of code of the server-side. The security
token code is not designed to handle creating a security token for a
gadget that is not within a region.
- A new servlet would have to be created for a very specific use case.
- Would defeat the purpose of a having a store of trusted gadgets. Any
third party gadget could request a security token and render
2.) Have any gadgets that could potentially be rendered through the
gadgets.views.openEmbeddedExperience api be registered on page
load. These gadgets would be locked, collapsed, and have their chrome
hidden. The container would have security token information about the
gadget but the gadget would not render on the page. This would require
database entries for each widget that could potentially be rendered on the
page.
At the moment, there is no ui for creating this.
Advantages:
- No major code changes
- Uses existing functionality
Disadvantages:
- Potentially inefficient to fetch the metadata for gadgets that will never
render.
- UI would have to be created to configure this.
Is there any other way to get this api to work that I am overlooking
If not, I would like to hear what the community thinks about solutions 1
and 2.
Thanks,
Robert O'Neill
From: Robert O'neill/Boston/IBM@IBMUS
To: "Rave Dev" <de...@rave.apache.org>,
Date: 11/01/2012 06:14 PM
Subject: Problem with shindig api in rave
I found an issue using the following shindig api in rave:
gadgets.views.openEmbeddedExperience(resultCallback, navigateCallback,
dataModel, opt_params);
I have a gadget on my rave dashboard. From within this gadget, I call
gadgets.views.openEmbeddedExperience to open a new gadget in a modal
dialog.
When the modal dialog appears, I get the error:
HTTP Status 401 - Malformed security token %st%Invalid security token %st%
My understanding of the issue is that the metadata for this gadget is
not preloaded when this api call is made. Instead, gadget metadata is
fetched once on page load for gadgets that are embedded in the
page. For gadgets that are dynamically added, there will be no
metadata and therefore no security token.
The only way to get around the issue at the moment is to add the
target gadget to the page. This properly preloads the gadget metadata
and retrieves the security token and the call to
gadgets.views.openEmbeddedExperience works as expected. For my use
case, this workaround will not suffice.
I am willing to dig into this issue and provide a fix.
Is there a specific place within the code where I should look first?
Thanks,
Robert O'Neill