>-----Original Message----- >From: Ryan Baxter [mailto:[email protected]] >Sent: Thursday, November 08, 2012 9:48 AM >To: [email protected] >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]> 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]>, >> 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 >> >>
