On Feb 6, 2008 4:37 AM, Reinoud Elhorst <[EMAIL PROTECTED]> wrote: > Now, I assume this will only work if there is some information on the > gadget-server on the "request URLs" for > http://www.example.com/something(since no discovery is in oAuth at the > moment). In addition, it should have > a consumer id (or be able to obtain one).
What I'd like to see: service providers support automatic registration of containers in gadgets for consumer keys. I've written up a proposal for how automated consumer registration could work: http://groups.google.com/group/oauth-extensions/t/bdd87bc7de25867c. Either the container or the gadget server would provide the consumer identification URL. What I think will happen: manual registration of consumer keys on both the service provider and container side, until hopefully this becomes popular enough that automatic registration is needed. > This also seems to be the > only part where Shindig needs any sort of persistent > storage (except the caching), and possibly shared storage (to be able to > cancel > accestokens, I guess). I think that initially I'd be happy to have > only a minimal implementation I think there's more than one way to make this work, and I agree that signed fetch is more important in the short term. I'd like to see two options for Shindig, one where the container and the gadget server share backend data stores, another where they don't. For the case where they do share data stores, I hope my patch to SHINDIG-35 serves as a starting point for the interface. For the case where there is no shared storage, maybe an IFPC implementation would work? For example, maybe something like this for signed fetch: - gadgets.io.makeRequest intercepts requests with AUTHORIZATION: SIGNED and performs an IFPC call back to the container with the makeRequest data. - the container HTML forwards the request to the container HTTP server with XHR, which then signs the request and returns the signed version. - the container HTML performs an IFPC back into the gadget. gadgets.io.makeRequest then forwards the signed request to the gadget server proxy, which fetches the data. An IFPC based implementation of full OAuth would be a pain, but it could probably be done. Maybe a starting point for Shindig would be to support two scenarios: shared storage: implement a java interface to your app data stores, and you get both signed fetch and OAuth. no shared storage: implement signing in your container, and Shindig will use IFPC to do the signing. No support for full OAuth. Cheers, Brian
