social-api folks: the proposal below for how to configure shindig to use real security tokens requires that the social-api side of the shindig tree inject a ContainerConfig object. The gadgets side of the code base currently gets the ContainerConfig by:
- reading java/gadgets/conf/gadgets.properties - extracting shindig.containers.default from that - injecting a ContainerConfig based on shindig.containers.default. Any objections to this happening on the social-api side as well? Is there an alternative mechanism that would work better? On Wed, Sep 24, 2008 at 5:03 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > On Wed, Sep 24, 2008 at 3:11 AM, Brian Eaton <[EMAIL PROTECTED]> wrote: > >> I just checked in a couple of classes that provide real security >> tokens, configured per-container. They are, for the moment, dead >> code. I don't want to remove the default usage of >> BasicSecurityTokenDecoder, because easy testing is too useful. >> >> Any thoughts on how Shindig java deployments should opt-in to using >> these classes? Hand-written Guice modules? Configuration in >> containers.js? >> > > container configuration is the way to go. It's actually pretty easy: > > - bind all possible variants with symbolic names (the class names are as > good as any) > - decoder code dispatches to appropriate variant based on container name. > > Making people write Guice modules is a non-starter. Shindig should be able > to be used without writing any code. >
