Dan, not sure I understand the benefits of having an array of what's allowed and an array of what's denied. If a feature is not in the allowed list than it is denied. We could have a deny list, but then in the majority of cases that list would be far bigger than what you want to allow.
-Ryan Email: [email protected] Phone: 978-899-3041 developerWorks Profile From: Dan Dumont/Westford/IBM@Lotus To: [email protected], Date: 09/01/2011 10:35 AM Subject: Re: Replacing The Gadget Blacklist Functionality What about a slight tweak to allow both behaviors in one file { "default" : { "http://www.google.com/ig/modules/horoscope.xml"; : { allow: ["views", "tabs", "setprefs", "dynamic-height", "settitle"], deny: null // null blocks all, empty array blocks none. }, "http://www.labpixies.com/campaigns/todo/todo.xml"; : { allow: ["setprefs", "dynamic-height", "views"], deny: null // null blocks all, empty array blocks none. } }, "foo" : { "http://example.com/gadget.xml"; : { allow: ["tabs"], deny: null // null blocks all, empty array blocks none. } } Where order is to apply all deny rules before allow rules (allow will override) From: Ryan J Baxter/Westford/IBM@Lotus To: [email protected], Date: 09/01/2011 10:22 AM Subject: Replacing The Gadget Blacklist Functionality As I look into how to add more functionality around gadget administration into Shindig (https://issues.apache.org/jira/browse/SHINDIG-1601) I came across the gadget blacklist which can be enabled/specified in shindig.properties. I am wondering what people think about combining that list into a more general gadget administration store. For the work I am doing around administrating the features and RPC services a gadget is allowed to use I have created a sample store in shindig, which is really just a JSON file. (You can replace this file via a guice module.) Here is an example... { "default" : { "http://www.google.com/ig/modules/horoscope.xml"; : ["views", "tabs", "setprefs", "dynamic-height", "settitle"], "http://www.labpixies.com/campaigns/todo/todo.xml"; : ["setprefs", "dynamic-height", "views"] }, "foo" : { "http://example.com/gadget.xml"; : ["tabs"] } } In essence this JSON file specifies which features each gadget is allowed to use in a given container. If a gadget requests a feature not in the array for that container the metadata request will fail for that gadget. You could also easily provide the same functionality the blacklist provides based off the information in this store, the store pretty much acts like a whitelist where the administrator needs to specifically allow gadget to render in a given container and provide the features that gadget is allowed to use. Obviously this is the inverse of what the blacklist did, but I don't think it makes sense to have to maintain two lists. Thoughts? -Ryan Email: [email protected] Phone: 978-899-3041 developerWorks Profile
