Thanks for the replies and shared thoughts. You can see what I had to do in the sample container for this: > > http://svn.apache.org/repos/asf/incubator/shindig/trunk/javascript/samplecontainer/samplecontainer.html
I didn't realize the sample container used a security token, I think that is indeed a good place to start. [...] > This will hopefully get easier in shindig over time as it supports more > and > more of opensocial. The first goal is to get a real opensocial container > running which gets data from the server (vs the mock data in the sample > container). I'm not sure if we can immediately add a js api for setting > the > opensocial container class (in the same way you set up the gadget js code) > but we can probably work on it. I indeed copied the opensocial-reference to opensocial-0.7, and added a new hyvescontainer feature. This works, but I need to specify in my gadget-xml a <Require feature="hyvescontainer" /> line. this isn't a problem for now, but I was wondering how this would work in the "final" version. The only thing I could think of (especially in the case of a shared server that would server several different non-predefined containers, would be to add an url parameter to the iframe src, with an url to a feature.xml to use. I was just wondering whether this was right. On 1/30/08, Brian Eaton <[EMAIL PROTECTED]> wrote: > > - user logs in to the container > - container uses the GadgetServer to render the gadget in 'Container' > mode (which doesn't do much at the moment) > - container uses GadgetSigner (which I'm renaming to > GadgetTokenSigner) to create the security token for the gadget I guess this is only useful if the container site is in java as well. Our site is in PHP, so I guess I need to convert the GadgetSigner to PHP (probably make some people on the PHP branch happy by conrtributing it back :) ). Am I correct in seeing that there is no actual signing (so no actual security) in there at the moment? [...] > Sounds good to me On 1/30/08, Kevin Brown <[EMAIL PROTECTED]> wrote: > > > Real production sites should always render the iframe on a different > domain > from the parent site This is critical for security. Without it, none of > the > other security solutions matter. > I was wondering about that. Obviously a separate domain is needed to protect the parent container page from the gadget, does this also protect gadgets from each other (in case multiple gadgets are put on one page)?
