On 11/19/12 3:18 PM, "Ryan Baxter" <[email protected]> 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. >> >> >> >> >> >> 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 >> >> >> >> >> >> >> >> >>
