Jesse, Wow! Lots to consume here. I'll look this over and post if I have further questions. I'm still confused about how the %host% inside the container.js gets massaged so that it makes the request to the domain shindig is running on instead of localhost. I know if I modified container.js to have the fully qualified domain name I then saw it making the request properly but as I said then I ran into the cross-domain issue. I'll do some experimenting here and let you know.
doug On 3/30/11 9:09 AM, "Ciancetta, Jesse E." <[email protected]> wrote: > 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! >
