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. <[email protected]>wrote: > On 11/19/12 6:11 PM, "Ryan Baxter" <[email protected]> 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. > ><[email protected]>wrote: > > > >> On 11/19/12 5:56 PM, "Ryan Baxter" <[email protected]> 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" > >><[email protected]<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. > >> >> ><[email protected]>wrote: > >> >> > > >> >> >> >-----Original Message----- > >> >> >> >From: Ryan Baxter [mailto:[email protected]] > >> >> >> >Sent: Wednesday, November 14, 2012 6:15 AM > >> >> >> >To: [email protected] > >> >> >> >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:[email protected]<javascript:;>] > >> >> >> >> >Sent: Thursday, November 08, 2012 9:48 AM > >> >> >> >> >To: [email protected] <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 > >> >> >> ><[email protected]<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. > >> >> >> >> >> > >> >> > > >> > >> > >
