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. <[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. > >> >> > >> >> 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" <[email protected] <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 > >> >> > >> >> > >> >
