Page History

...

To enable preliminary testing, oauth support can be enabled by editing the config/oauth.js json file. This file lists the consumer secrets that a gadget uses to communicate with a given service. For example, assume the gadget at http://one.author.com/niftyGadget.xmlImage Removed has the following service declared in its xml file:

...

Once this store is written, it needs to be registered in a new Guice module. The new Guice module can reuse some parts of OAuthModule.

The OAuthCrypterProvider is used to provide encryption for some client-side state. The Shindig implementation is suitable for production use, provided that you share a shindig.oauth.state-key file across all of your servers. The contents of that file should be a long (20 or 30 characters) secret string. If your organization has standard procedures for managing secret keys in production servers, you should replace OAuthCrypterProvider to hook into a custom implementation of BlobCrypter.

The OAuthRequest class is suitable for production use. If you need to add additional parameters to OAuth signed requests beyond the standard opensocial parameters, you will want to write your own provider, or possibly your own implementation of RequestPipeline.

The BasicOAuthStore class is not suitable for production use. You need to tie into a persistent storage system your Guice Module.

Enabling server-side OAuth for the REST api

...