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! 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 > > > >
