On Wed, May 14, 2008 at 9:42 AM, Dirk Balfanz <[EMAIL PROTECTED]> wrote:
> Yes, BasicGadgetOAuthTokenStore needs to be replaced. Actually, I > would recommend just ignoring it in your own adoption of Shindig. > There is another reason you want to replace some of the token storage > stuff with your own implementation - the provided classes keep OAuth > tokens in memory, so they are lost after every restart. But, yes, the > oauth.json file you mention is also a reason. > > You can replace the implementation by injecting your own > OAuthFetcherFactory class like this: > > - write your own implementation of OAuthStore (i.e. a replacement for > BasicOAuthStore (as opposed to a replacement for > BasicGadgetOAuthTokenStore)) - make it something that stores tokens in > persistent storage, reads consumer secrets from storage that can be > updated at runtime, etc. > - write your own implementation of OAuthFetcherFactory (and inject that) > - in your implementation of OAuthFetcherFactory, when you make a new > OAuthFetcher, pass in something like "new GadgetOAuthStore(new > YourOAuthStoreImpl())" as the first argument to the OAuthFetcher > constructor. > > To summarize: Ignore BasicGadgetOAuthTokenStore and BasicOAuthStore. > Replace BasicOAuthStore with your own implementation. Get that > implementation to be used through a new injected OAuthFetcherFactory > implementation. Does this make sense? > > I wrote the OAuth token storage code, and the use case I had in mind > requires different OAuthStore implementations for different > GadgetTokens, so the injection of a new OAuthFetcherFactory was good > enough for me. If this makes things inconvenient for other use cases, > I'm sure we can come up with ways to make this better! The default OAuthStore should work "out of the box" with the default encrypted SecurityToken, but the current wiring still requires that you modify some code to force the SecurityToken to use real crypto instead of the plain text form. I'm going to do some work to make working with both OAuth and Signed requests quite a bit simpler for integrators, but any "production" solution is going to require storage -- which means implementation-specific choices. Ideally, I'd love to see projects (even subpackages in Shindig) that handle providing different implementations for these things, along the lines of what Christian and Ian have been working on. Ideally, I'd like to get to the point where the only integration points that are "required" are things that need persistence. > > > Dirk. > > > On Wed, May 14, 2008 at 8:29 AM, Lieven Dekeyser <[EMAIL PROTECTED]> > wrote: > > Hi, > > > > If I'm not mistaken, each opensocial app can have its own OAuth consumer > > keys, and these should be defined in config/oauth.json. > > The problem with this approach is that oauth.json is static, so when new > > applications are added, new keys have to be added to this file and the > > server has to be restarted. > > Therefore I think it makes more sense to make our own > GadgetOAuthTokenStore > > which reads the keys from database, but it seems like this is not > injectable > > with Guice yet. > > > > Does this make sense? Are there plans to make this more dynamic? > > > > Lieven Dekeyser > > Desktop Application Developer > > > > Netlog NV > > Emile Braunplein 18 > > B-9000 Ghent > > Belgium > > > > > > > > >
