Whitelisting Gadgets

To enable gadget whitelisting set the property  gadgets.admin.enableGadgetWhitelist in your containers configuration file (container.js) to true.  You also need to provide an implementation for the GadgetAdminStore interface in Shindig.  Shindig calls the isWhitelisted method in this interface to determine whether a gadget is on the whitelist or not.  Your implementation of this method can point to whatever whitelist store you may have.

Enabling and Disabling Features For Gadgets

Shindig 3.0 provides administrators a way to say which features are disable or enabled for a specific gadget in a specific container.  To enable this functionality set gadgets.admin.enableFeatureAdministration to true in your container's configuration file (container.js).  You also need to provie an implementaiton for the GadgetAdminStore interface.  This will interface with whatever you are storing your feature admin information in.  In Shindig the reference implementation uses a static JSON file.  However a quick overview of this file will give you an idea of what you can do.

{
  "default" : {
    "gadgets" : {
      "http://www.google.com/ig/modules/horoscope.xml" : {
        "features" : {
          "names" : ["views", "tabs", "setprefs", "dynamic-height"],
          "type" : "blacklist"
        }
      },
      "http://www.labpixies.com/campaigns/todo/todo.xml" : {
        "features" : {
          "names" : ["setprefs", "dynamic-height", "views"],
          "type" : "whitelist"
        }
      },
      "http://localhost:8080/samplecontainer/examples/media-openGadgets/Media.xml" : {
        "features" : {
          "names" : [],
          "type" : "blacklist"
        }
      },
      "http://localhost:8080/*" : {
        "features" : {
          "names" : [],
          "type" : "whitelist"
        },
        "rpc" : {
          "additionalServiceIds" : []
        }
      }
    }
  }
}

You can see in this example that for the default container we have four gadgets which we have configured feature administraiton data for.  Take the horoscope gadget for example, in this case the admin has whitelisted the features views, tabs, setprefs, and dynamic height features. The admin can either specify whether the list of features is for a whitelist or blacklist.  If the horoscope gadget tried to use any other features besides the ones listed the gadget will not render.  (This would only be true for required features, if a gadget requested an optional feature that was denied the gadget would still be allowed to load but the javascript for that feature would not be provided to the gadget.)  In fact if that container requests the metadata for this gadget the metadata request will fail because the server figures out if the gadget is trying to use any features that it is not allowed to use.

Securing RPC Calls Made To The Container

Any gadget has the ability to make an RPC call to any RPC endpoint.  This can be dangerous if the RPC endpoint returns data which may be sensitive information.  In order to secure the RPC endpoints a gadget is allowed to call we tie into information specified in the feature XML file.  Feature developers should specify any RPC endpoints they call in their feature XML.  They can do this by using the <uses> tag.

<feature>
  <name>foo</name>
  <dependency>bar</dependency>
  <gadget>
    <script src="foo_gadgets.js" />
    <api>
      <uses type="rpc">ee_gadget_rendered</uses>
    </api>
  </gadget>
</feature>

The uses tag basically allows the feature developer to declare the RPC endpoints their code uses.  This information will get gathered for every feature a gadget uses and sent down to the container when the gadgets metadata is requested.  The container will then use this information to check every RPC call made from the gadget to the container to see if the RPC service ID the gadget is calling is allowed.  To enable this functionality set enableRpcArbitration to true in your containers configuration.

There may be scenarios where you may want to provide RPC services but not declare them in features. In these scenarios you should specify the which gadgets are allowed to use these RPC service ids. There is a method in the interface GadgetAdminStore called getAdditionalRpcServiceIds, which returns a set of additional RPC service IDs you want to allow for that gadget. In the default implementation in Shindig, you can specify this list on a per gadget basis in gadget-admin.json by setting an array of service ids in the additionalServiceIds property. This property should be part of the rpc object for each gadget.

{
  "default" : {
    "gadgets" : {
      "http://localhost:8080/*" : {
        "features" : {
          "names" : [],
          "type" : "whitelist"
        },
        "rpc" : {
          "additionalServiceIds" : ["rpc_service_1","rpc_service_2"]
        }
      }
    }
  }
}