Hi Jesse, Thanks for the great information. Regarding your questions:
-- Security Tokens - You are correct in that the GadgetHandlers servlet can create the security token (gadgets.token). The TokenResponse that is generated in GadgetsHandlerService will contain the encrypted token. You'll need to change your configuration in container.js. Look for gadgets.securityTokenType. - In the common container's service.js, you will find osapi.container.Service.prototype.getGadgetToken which does this http request. On the client side, it looks like the common container refresh mechanism will take care of the initial security token fetch. It also uses the auth-refresh feature to update the security token once fetched, which simply delegates to the shindig.auth feature. -- User prefs - I have yet to find a mechanism for persisting user prefs, but I'll keep digging. However, there is a persistence API for app data. Take a look at JPASocialModule. It binds the AppDataService to AppDataServiceDb which is setup to use an Apache Derby backend. By default this isn't used as the SampleModule binds the AppDataService to the JsonDbOpensocialService instead. I hope that makes sense. I'm still digging through this code myself to understand the big picture. Best regards, -Stanton From: "Ciancetta, Jesse E." <[email protected]> To: "[email protected]" <[email protected]>, Christiaan Hees <[email protected]>, Cc: Michael Hermanto <[email protected]>, Kris Vishwanathan <[email protected]> Date: 03/30/2011 09:09 Subject: RE: Shindig and webapp on same host/domain or not? We make the calls to fetch gadget metadata on the server side as well and then cache the results in the database we have backing our custom container. So basically when we add a new gadget to our gadget repository we fetch the gadget metadata at that time in Java code (part of our custom container) and parse the response -- picking out the gadget user prefs, their default values, gadget sizing prefs, etc and put them into our database. Then when we go to render gadgets at request time, we take all of those values from our local database and use them when constructing the gadget iframe URL's. We also have support to refresh the gadget metadata from an admin screen, and if we find that and values have changed we update our database accordingly (user prefs have been added/removed, default values have changed, etc). We've open sourced our code so you can have a look at it to see if it could help you -- its available at the following url: http://code.google.com/p/osec/ You could also look at Partuza for a PHP based example of how this stuff is done: http://code.google.com/p/partuza/ And I'm sure there's other containers around these days you could use as a reference as well -- there really wasn't though when we started our project (at least there wasn't a Java based container we could find) which was why we built our own. We're also working with a few other groups on an Apache Incubator project called Rave which you can get more details on here: http://wiki.apache.org/incubator/RaveProposal We're still in the early stages with Rave but things are definitely starting to pick up there. I haven't used common container myself but from what you're describing it sounds like it must fetch the gadget metadata on every page request directly from shindig and then use the response to construct the gadget iframe urls. And if that's the case, and you've got the common container JS loaded up on a page served from domain X and it then tries to do an XHR to domain Y, as you've found it would definitely result in a cross domain security error. I think the easiest way to solve that would be to implement a proxy mechanism on domain X which would proxy the metadata calls back to domain Y on the server side -- so the common container code would then be making the XHR's to domain X which would be allowed (you'd have to dig around in the common container code though to figure out how to get it to call domain X). As Isaiah pointed out you should be able to use something like mod_proxy to do that pretty easily or as Michael points out in the thread you referenced you could try some tricks with hidden iframes sourced from domain Y to proxy requests back and forth. One other note about security is that just having a different domain by itself for rendering gadgets isn't really sufficient -- to be completely secure you really want to be using wildcard DNS on your gadget rendering domain so that gadgets not only render on a completely different domain than your container (so they can't get to things like your SSO cookies) but they also render on unique sub domains from each other so they can't reach into each other's DOM's and pull out data. Shindig supports this with a feature called locked domain -- the default scheme to generate the unique sub domains is <hash-of-gadget-spec-url>.your-gadget-domain.foo. Whether or not all this DNS isolation is necessary though really depends on your use case -- if you're going to be rendering potentially untrusted gadgets written by third parties then you definitely want to be sure they're isolated on a jail domain, but if you're just serving up gadgets that you write it's probably not much of a concern. Some other things off the top of my head that you're going to have to figure out how to deal with (and maybe they're already handled in common container but after a brief look I didn't see how/where): -- Security Tokens. You need encrypted security tokens to embed in the gadget iframe urls so that Shindig securely knows who the user is (and various other bits of info). I see that common container has support to refresh tokens, but I don't see where tokens come from in the first place. They have to be generated server side somewhere by a webapp who securely knows who the current user is (since they rely on symmetric encryption, and doing it on the client side would mean the key would be on the client side). Maybe that's part of what the metadata servlet in Shindig does these days? That would seem to imply SSO though between you're container and shindig domains which we've already said we often want to avoid... -- User prefs. It looks like common container is fetching user prefs with the metadata call -- last time I looked (which was a while ago) Shindig didn't support storing user prefs -- it only handled appdata (which out of the box is in an in-memory store -- you'll need to inject an implementation of the AppDataService that does real persistence if you want to use appdata). If someone could answer those questions about how common container works I'd appreciate it -- I've been meaning to have a closer look at it myself but haven't had a chance. Hope that helps! >-----Original Message----- >From: Davies,Douglas [mailto:[email protected]] >Sent: Wednesday, March 30, 2011 8:46 AM >To: Christiaan Hees >Cc: [email protected]; Michael Hermanto; Kris Vishwanathan >Subject: Re: Shindig and webapp on same host/domain or not? > >Can you expound on that? What do you mean you made the metadata call >server side? What did you modify to do this? Won't I still have issues >making other calls. Won't the web app on my localhost still use the >relative path to make gadget API calls? I'm not sure I understand how >the %host% substitution happens for the entries in container.js. > >Sent from my iPad > >On Mar 30, 2011, at 4:34 AM, "Christiaan Hees" <[email protected]> >wrote: > >> I ended up doing the metadata call on the server side instead of the >> client to avoid this issue and it works. But this is still using the >> old container code, so I'm not sure if it's the best solution for you. >> >> On Wed, Mar 30, 2011 at 3:50 AM, Davies,Douglas <[email protected]> >wrote: >>> I'm pretty sure it's just using one of the relative urls from >container.js, because I know that if I modified all the urls on the >server side I then saw it making the request to the shindig server >correctly. However that request fails because there is no post data in >the request for gadget metadata. Not sure if that is a cross domain >issue or something else. Hopefully someone will have an idea. Thanks. >>> >>> Doug >>> >>> Sent from my iPhone >>> >>> On Mar 29, 2011, at 9:18 PM, "Ryan J Baxter" <[email protected]> >wrote: >>> >>>> Hi Doug, I think you are right you should be striving for situation >3, at >>>> least that is my understanding. We have not yet tried to separate >Shindig >>>> and the web app so they are running on two different domains. The >only >>>> thing I can suggest is just diving into the common container code >and >>>> figure out how it is figuring out the domain to use. Off the top of >my >>>> head I cannot recall how the common container is doing this. Mike >>>> Hermanto may know more.... >>>> >>>> -Ryan >>>> >>>> Email: [email protected] >>>> Phone: 978-899-3041 >>>> developerWorks Profile >>>> >>>> >>>> >>>> From: "Davies,Douglas" <[email protected]> >>>> To: Kris Vishwanathan/Fairfax/IBM@IBMUS, ><[email protected]>, >>>> Date: 03/29/2011 04:35 PM >>>> Subject: RE: Shindig and webapp on same host/domain or not? >>>> >>>> >>>> >>>> Hmmm... Now I am seriously confused. I'm not sure we are both using >the >>>> same terminology here. >>>> >>>> I want this >>>> >>>> Server 1 (domain x) >>>> ------------------ >>>> Shindig Server >>>> >>>> Server 2 (domain y) >>>> ------------------ >>>> A webapp that uses javascript gadget api to communicate with shindig >>>> server and render gadgets into iframes >>>> >>>> The problem is that server 2 is trying to call itself for the gadget >api >>>> calls, since the container javascript is using relative paths. >>>> >>>> As Isaiah then mentions, he is trying to do a rewrite rule on server >2 >>>> to redirect the requests to the shindig server, however I suspect >he'll >>>> run into cross-domain issues here (as suggested by the common >container >>>> issue thread I referred to earlier). >>>> >>>> I'm sure there is just some configuration or concept I am missing >here. >>>> >>>> doug >>>> >>>> -----Original Message----- >>>> From: Kris Vishwanathan [mailto:[email protected]] >>>> Sent: Tuesday, March 29, 2011 3:27 PM >>>> To: [email protected] >>>> Cc: Davies,Douglas; [email protected] >>>> Subject: Re: Shindig and webapp on same host/domain or not? >>>> >>>> Scenario three is a reasonable approach and that's how most of the >>>> Social >>>> networking sites run. >>>> >>>> Your deployment can look as below: >>>> >>>> Server1 (Domain X) >>>> ------------ >>>> >>>> Shindig Server >>>> Common Container >>>> index.html or your webpage that bootstraps container and your page >etc.. >>>> >>>> >>>> Server 2 (Domain Y) >>>> ------------- >>>> Your custom webapp >>>> Other gadget apps >>>> >>>> >>>> Hope it helps. >>>> >>>> Thanks and regards >>>> >>>> Kris Vishwanathan >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>
