On Wed, Jan 30, 2008 at 5:40 AM, Reinoud Elhorst <[EMAIL PROTECTED]> wrote:
> 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. What does your hyvescontainer feature do/supply? We're currently thinking about how a shared server can satisfy the needs of several different containers when they have slightly different configuration parameters, data formats, and so on. Container-mediated communication (gadget-ifpc-to-container and back) is in many cases a viable solution since it offloads container-specific logic to the container itself, but as mentioned several times can have performance costs. --John > > > 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)? >
