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