On Feb 4, 2008 10:14 AM, Brian Eaton <[EMAIL PROTECTED]> wrote: > On Feb 4, 2008 9:59 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > This puts too much burdeon on potential consumers of Shindig to have to > > place app data server logic into the gadgets server. We've been > > intentionally avoiding this from the beginning. The GadgetServer > shouldn't > > be required to know anything about the app data server. All > communication > > with the app data server can happen over the proxy (if on a different > host > > name), directly within the gadget via XHR if on the same host, or over > IFPC > > (in the container mediated model). The security token is an opaque > string > > that is simply passed on in this case. The only time the gadget server > > actually does anything with the security token is when it is being used > for > > operations like locking down the open proxy. > > You've lost me. Can you give me some details on how this would work, > for either the IFPC or the proxy model? > > In particular: > - how would setprefs be implemented?
Up to the container; this is already container mediated (doesn't really have any impact on this discussion). - how would phone home be implemented? This probably is best served in the proxy, which is why I suggested starting from scratch with a new mechanism for this. The security token / GadgetSigner was devised long before we had any concept of signed or authenticated requests as a part of the gadgets API. This doesn't actually require knowledge of the app data server, though, it only requires knowledge on how to decode the token. - how would locked domains be implemented? Also has nothing to do with this necessarily (although you could require that the GadgetToken be able to return the locked domain, but I think this is overkill). I think the best implementation of locked domain for shindig is either an md5 or sha1 hash of the gadget url. Creating a collision is virtually impossible because it would require making said collision with a fixed prefix (limited to host names the attacker can control) and a finite length (~2k for the url parameter). It's a trivial implementation, and at the worst case produces exactly the same number of unique sub domains as any other implementation would (by definition; locked domain requires a unique domain for every possible gadget).
