On Mon, Apr 14, 2008 at 3:05 PM, Raymond Auge <[EMAIL PROTECTED]> wrote: > On Mon, 2008-04-14 at 14:47 -0700, Brian Eaton wrote: > > > You can't trust javascript to specify the app id, it has to come from > > the gadget server (and be signed with the gadget server's private key) > > in order to be trusted. > > In this statement... is "gadget server" really "gadget container" as I > would imagine that the gadget "server" might be some remote site > providing the "application's" blob... where the "gadget container" is > the one providing the runtime environment. I'd imagine that the > "container" is the one responsible for providing the signed token... not > the gadget "server"?
I'm going to ignore all terminology for a minute, because it makes my head hurt. Yeah, your understanding is correct. The thingy creating links to Shindig's /gadget/ifr endpoint needs to include a security token on the URL fragment when it creates the link. The javascript inserted by Shindig when it renders the gadget should snarf the security token off the fragment, and include it in makeRequest messages passed to Shindig. When Shindig sees a makeRequest message with a request for signing, it should decode/verify the security token, then include some bits of information about the owner/viewer/appid when it forwards the request to whatever server the gadget wants to talk to. > Can we have a sample of a signed token render, even if it's not fully > implemented in code... even just in a README??? Or is this still > premature? You can build one on top of BlobCrypter pretty easily. There's been talk about hooking up the sample container to BlobCrypter so that there's an easy demo, so far no one has grabbed that work. Cheers, Brian
