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? What if today I had a bunch of widgets on a page wouldn't that be essentially the same thing?
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 > >> > >> >
