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