Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.0.0
-
None
-
Shindig trunk.
Java 5
Windows
FireFox, Safari, Chrome
Description
This patch is an initial alpha implementation by Javier Pedemonte (OpenAjaxHub/IBM) based on the proposal described here
http://wiki.opensocial.org/index.php?title=Incorporate_Open_Ajax_Hub_as_Pub-Sub_Mechanism_for_OpenSocial_1.next
While there are still more work, the patch provides a new pubsub feature which uses OAHub as the underlying eventing model.
The /content/container/sample-pubsub-2.html demonstrates a simple pubsub example using the feature.
API documentation can be found in the comments of the /javascript/features/pubsub-2/pubsub-2.js
Attachments
Attachments
- pubsub2.patch
- 118 kB
- Han Thi Ngoc Nguyen
Issue Links
- depends upon
-
SHINDIG-1409 Security updates to RPC
- Resolved
Activity
Update patch and description: http://codereview.appspot.com/1247044/show
I am working on some project which need to use shindig as a reference. But I find I can not see the pubsub sample work fine within Shindig 1.1-BETA5, neither in Shindig 2.0.
This was once dicussed by here:
http://mail-archives.apache.org/mod_mbox/shindig-dev/201005.mbox/<AANLkTimw9GNKzGb_ARQEV1THVyPH_tM8dUO9XLlVB7nP@mail.gmail.com>
If I apply the patch provided in this bug to 2.0 Shindig, the new pubsub sample(pubsub2) works fine. But the original pubsub sample does not work still.
My question is:
1) Did the pubsub sample once work in some Shindig version?
2) Does the new patch use same underlying API as the original pubsub API?
Thanks.
I don't see this pubsub2 feature applied in Shinding2.0-RC1. What need to be done to get this patch applied for Shindig 2.0 release?
Kai:
I have updated the patch (on codereview) to fix the 'pubsub' sample.
In response to (2), this patch uses OpenAjax Hub to do the pubsub events and as such implements a new API. See the comments at the top of pubsub-2.js and pubsub-2-router.js.
STATUS OF LATEST PATCH (SET #4)
- Adds new pubsub-2 feature.
- Adds the following new APIs:
- gadgets.byId()
- gadgets.rpc.config()
- For setting config parameters on rpc connection. Right now only
takes a security callback. - gadgets.rpc.removeReceiver()
- gadgets.rpc.getReceiverOrigin()
- Updated NIX transport to support parent verification, given a valid relay file.
- Updated WPM transport to check origin on message reception. Also added checks for non-async WPM and Opera 9.x's use of "event.domain" instead of "event.origin".
- Hook for possible frame phishing in rpc.js, given a valid relay file.
QUESTIONS/REMAINING ISSUES
- Not sure of the best place to put gadgets.byId(). For now, I've put it in core.util/util.js, but that needs to be fixed.
- In shindig-container.js, since OpenAjax Hub creates the iframe, needed to split code up into two cases: the case where gadget requires the 'pubsub-2' feature and therefore uses OAA Hub to create and manage the iframe; and the existing case where the iframe is created in shindig-container.js. This code isn't pretty, since I need to do a metadata request for the gadget. Ideally, I should be using the new container code (the 'shindig.container-1.0' feature), since it fetches and caches the gadget metadata on the container side. Will this new container code be the default container for Shindig 2.0?
- Not sure about gadgets.rpc.config(). Need a way to set the security callback function. In a previous discussion, we decided to go with config() rather than a function specifically for the callback (see http://wiki.opensocial.org/index.php?title=PubSub.next_Proposals#Secure_rpc), since we could expand it in the future for other uses.
ANOTHER ISSUE: The update to NIX to support parent verification requires two auth tokens: one from the parent and one from the child. The code I wrote just generates a random token on the child side. What would be the best way to allow a gadget to provide this auth token? Given that RPC initializes the connection to the parent when rpc.js is evaled, the child auth token cannot be provided on gadget load (it's too late). Perhaps there is no good solution and we'll just use a randomly generated child token?
Hi, I also work with shindig in my project, but i can't run pubsub function.
Please give me advice any released shindig version that pubsub worked
I am working on a portal framework, which allows to include Shindig-rendered gadgets into enterprise applications. We are also required to allow these Applications to interact with Gadgets by sending / receiving notifications. We decided to implement this mechanism using OpenAjax Hub. It plays extremely well with the PubSub-2 implementation, and I already did a proof-of-concept on this.
The only issue I have is that on the Applicaiton side the preferred implementation is based on TIBCO version of OpenAjax Hub (due to its caching feature), and not on the reference implementation, as PubSub-2 is. Can you please suggest an approach to resolve this.
Hi there, I too am working on a portal framework that uses Shindig to allow third party developers to create gadgets for our service. I was wanting to experiment with these new pubsub controls, but for some reason all patches beyond patch set 2 don't seem to do anything when attempting to apply them via tortoise svn. Is there something I'm missing here? Anybody else experiencing issues with these patches? Any help with this would be greatly appreciated.
@ Kevin Parkerson, I'm not sure which version of Shindig you're using. This patch has been applied to Shindig2.0.0 release and should be in Shindig trunk as well. Perhaps, upgrading to the latest release to leverage the feature?
@Han Nguyen, thank you for the quick reply. I've been using the Shindig 2.0.0 release for a while now through tomcat, using the shindig-server-2.0.0.war file provided from http://shindig.apache.org/download/index.html. Oddly enough, I'm not seeing the pubsub-2 feature inside the shindig-features-2.0.0.jar... it should be listed inside the ...\shindig-features-2.0.0\features\ directory right? Either way it helps to know the patches have been applied to the latest version, so thanks again for that information.
@ Kevin Parkerson, pubsub-2 is added under /features-extras. If you're running shindig2.0.0 war, then the example below should work
http://<server:port>/container/sample-pubsub-2.html
@Han Nguyen oh wow, why I never thought to look outside of shindig-features-2.0.0.jar is a mystery... must be a case of "Friday stupidity"... thanks for the help!
Hi there, me again. Nice work on the pubsub-2 feature, we've used it to successfully accomplish many of our goals on an application running within the Tomcat ROOT directory. However, when trying to run our application outside ROOT, we are getting an interesting error upon gadget rendering that looks something like this:
POST http://localhost/gadgets/metadata?st=john.doe:john.doe:appid:cont:url:0:defaultPOST http://localhost/gadgets/metadata?st=john.doe:john.doe:appid:cont:url:0:default404 Not Found 45ms
The application is .NET 4.0 on a Windows machine running IIS 7 and the containers are calling into shindig. IIS is doing the following with the request:
Requested URL: http://localhost:80/gadgets/metadata?st=john.doe:john.doe:appid:cont:url:0:default --> Physical Path: D:\Inetpub\gadgets\metadata
Is there some way to bypass getting the metadata? We've already tried setServerBase and it doesn't seem to work correctly. Any help would be greatly appreciated. Thanks in advance!
@ Kevin,
How do you change Shindig context root, specifically the serverBase value set in the function of shindig-container.js below?
shindig.BaseIfrGadget = function(opt_params) {
shindig.Gadget.call(this, opt_params);
this.serverBase_ = '/gadgets/'; // default gadget server
this.queryIfrGadgetType_();
};
Looks like serverBase value is hardcoded to '/gadgets/', and we don't know how it can be dynamically set, but we've learned that if it's not updated with the context root
accordingly then the gadget won't be rendered, is that what you're experiencing?
setServerBase() won't help in this case because 1. the above function is invoked prior setServerBase() and 2. this.serverBase is hardcoded in that function.
So to get around, we currently set serverBase as opt_params when creating a gadget. For example: with "/shindig" as a context root, we create gadget0 as follow
var gadget0 = shindig.container.createGadget(
);
Then, we modified shindig.BaseIfrGadget = function(opt_params) in shindig-container.js so it will set the serverBase from the opt_params input
shindig.BaseIfrGadget = function(opt_params) {
shindig.Gadget.call(this, opt_params);
if(opt_params.serverBase)
else
{ this.serverBase_ = '/gadgets/'; // default gadget server } this.queryIfrGadgetType_();
};
Alternatively, you can hard code the context root "/shindig" in the serverBase value as seen here
shindig.BaseIfrGadget = function(opt_params) {
shindig.Gadget.call(this, opt_params);
this.serverBase_ = '/shindig/gadgets/'; // default gadget server
this.queryIfrGadgetType_();
};
I think the question is left for anyone who knows how to update the context root value in the function above dynamically. Let us know if that helps.
Javier, do you have other insight for this?
Han
@Han,
Ah yes, modifying the function within shindig.container.js does the trick! We were trying to override shindig.BaseIfrGadget in a separate script on the page itself, but for some reason it wasn't taking. Dynamically modifying the serverBase would be nice, but for now the method you've suggested will be just fine. Thanks again for the help!
Good to hear Kevin. I'll open a bug if there's no suggestion on how to set the value dynamically BOD.
Han
Hi there,
I have yet another question for your team. Thus far we've been using the default gadget rendering methods (shindig.container.createGadget, shindig.container.addGadget, and ashindig.container.renderGadget) in order to utilize the pubsub-2 feature. However, we would like to be able to render gadgets programmatically by generating the url as specified on https://cwiki.apache.org/confluence/display/SHINDIG/iframe+url+format and setting it to the src element of an iframe. We've done this in the past and features such as RPC, tabs, and the old pubsub mechanism worked without problem, but because pubsub-2 changes how the gadgets are rendered it seems they cannot utilize the new pubsub-2 feature. I assume this is the result of not registering the appropriate values with the Shindig/OAA gadget framework. Is there a way to add programmatically created gadgets to the framework as the default rendering methods do? As before, any help with this would be greatly appreciated. Thanks again!
Kevin
@Ilya Shtein, the pubsub-2 makes use of and interacts with a version of the OpenAjax Hub that is written on top of Shindig's RPC code. In order to use TIBCO's OAHub, it would need to be updated so it was based off of the latest version of the OAHub. Then, it should be easy to build a version of Shindig where you have replaced the reference impl of OAHub (in shindig/extras/src/main/javascript/features-extras) with the new TIBCO version.
@Kevin Parkerson, OpenAjax Hub was implemented such that the code creates and manages the iframe. So what you want to do (create iframe, then set 'src') isn't currently possible with OAHub. I'll keep this in mind going forward, though, and see if there's a good way to add this to OAHub.
i am having the same issue han mentioned regarding hard coded server base. shouldn't this value come from shindig's container config files (container.js)?
additionally, the fact that the constructor performs a metadata request without the ability fo determine if one is even required seems excessive: in my case (as i am sure in others) i batch the metadata requests prior to generating the gadgets in order to save the extra roundtrips, however, this constructor forces many more metadata requests that are not really required as i can pass the required info (pubsub2?) to shindig.container.createGadget function and save the extra roundtrips.
Hi Han,
Can you upload this to codereview.appspot.com?
I think that having some review would be useful, plus there may be better ways of accomplishing what you're trying to do.
Thanks!