On Feb 4, 2008 11:36 AM, Reinoud Elhorst <[EMAIL PROTECTED]> wrote: > On 2/4/08, Kevin Brown <[EMAIL PROTECTED]> wrote: > > > > 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). > > > > I think this is important for this discussion. This is because the gadget > server should only proxy for gadgets that are locked to that domain.
This isn't really a strong requirement, but it can be an implementation detail. When you validate a token (by calling Gadget*Signer.createToken), you can trivially validate that the locked domain host matches the url for the gadget it was signed for.
