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. >> >> >> >> >> >> >> > >> >>
