You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Ryan J Baxter <rj...@us.ibm.com> on 2011/09/01 16:20:12 UTC
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: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
Re: Replacing The Gadget Blacklist Functionality
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Good suggestion Brian. I will do that, thanks.
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Brian Lillie/Austin/IBM@IBMUS
To: dev@shindig.apache.org,
Date: 09/01/2011 02:07 PM
Subject: Re: Replacing The Gadget Blacklist Functionality
Ryan was referring to a specific gadget blacklist capability available in
the container, not necessarily to allowing the allow/deny on the features
list, though of course it could be used in any of the cases.
It would seem that if you want to add additional administrative attributes
to a generalized store, that you might also need to identify the
attributes
being added.
{
"default" : {
"http://www.google.com/ig/modules/horoscope.xml" : {
"features" : {
allow: ["views", "tabs", "setprefs",
"dynamic-height", "settitle"],
deny: null //
null blocks all, empty array
blocks none.
}
},
"http://www.labpixies.com/campaigns/todo/todo.xml" : {
"features" : {
allow: ["setprefs", "dynamic-height",
"views"],
deny: null // null blocks all, empty array
blocks none.
}
},
"http://www.example.org/badgadget.xml" : { "blacklisted" : "true" }
},
"foo" : {
"http://example.com/gadget.xml" : {
allow: ["tabs"],
deny: null // null blocks all, empty array blocks none.
}
}
From: Dan Dumont/Westford/IBM@Lotus
To: dev@shindig.apache.org,
Date: 09/01/2011 09:36 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: dev@shindig.apache.org,
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: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
Re: Replacing The Gadget Blacklist Functionality
Posted by Brian Lillie <br...@us.ibm.com>.
Ryan was referring to a specific gadget blacklist capability available in
the container, not necessarily to allowing the allow/deny on the features
list, though of course it could be used in any of the cases.
It would seem that if you want to add additional administrative attributes
to a generalized store, that you might also need to identify the attributes
being added.
{
"default" : {
"http://www.google.com/ig/modules/horoscope.xml" : {
"features" : {
allow: ["views", "tabs", "setprefs",
"dynamic-height", "settitle"],
deny: null // null blocks all, empty array
blocks none.
}
},
"http://www.labpixies.com/campaigns/todo/todo.xml" : {
"features" : {
allow: ["setprefs", "dynamic-height",
"views"],
deny: null // null blocks all, empty array
blocks none.
}
},
"http://www.example.org/badgadget.xml" : { "blacklisted" : "true" }
},
"foo" : {
"http://example.com/gadget.xml" : {
allow: ["tabs"],
deny: null // null blocks all, empty array blocks none.
}
}
From: Dan Dumont/Westford/IBM@Lotus
To: dev@shindig.apache.org,
Date: 09/01/2011 09:36 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: dev@shindig.apache.org,
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: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
Re: Replacing The Gadget Blacklist Functionality
Posted by Dan Dumont <dd...@us.ibm.com>.
You're probably right. I wrote it down as 1 deny per entry in the map
here, but it makes more sense if it were a blanket list for all gadgets,
that each one could overwrite.
Generally though, I agree that a whitelist is probably more useful than a
blacklist. You may also want to indicate some way of easily specifying
all features in the whitelist... ["*"] or something.
From: Ryan J Baxter/Westford/IBM@Lotus
To: dev@shindig.apache.org,
Date: 09/01/2011 02:04 PM
Subject: Re: Replacing The Gadget Blacklist Functionality
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: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Dan Dumont/Westford/IBM@Lotus
To: dev@shindig.apache.org,
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: dev@shindig.apache.org,
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: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
Re: Replacing The Gadget Blacklist Functionality
Posted by Ryan J Baxter <rj...@us.ibm.com>.
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: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Dan Dumont/Westford/IBM@Lotus
To: dev@shindig.apache.org,
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: dev@shindig.apache.org,
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: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
Re: Replacing The Gadget Blacklist Functionality
Posted by Dan Dumont <dd...@us.ibm.com>.
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: dev@shindig.apache.org,
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: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
Re: Replacing The Gadget Blacklist Functionality
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Henry, I was actually thinking of having it be it's own file, with it's
own guice module. I think this provides the most flexibility to the
implementer. I know for our use case it would be simpler for us to just
replace a guice module as this administration information is stored
separately from the configuration information in our application.
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Henry Saputra <he...@gmail.com>
To: dev@shindig.apache.org,
Date: 09/01/2011 03:16 PM
Subject: Re: Replacing The Gadget Blacklist Functionality
I was actually thinking about moving it to container.js file.
Probably we could also include the new admin setup into container file
itself?
- Henry
On Thu, Sep 1, 2011 at 7:20 AM, Ryan J Baxter <rj...@us.ibm.com> wrote:
> 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: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
Re: Replacing The Gadget Blacklist Functionality
Posted by Henry Saputra <he...@gmail.com>.
I was actually thinking about moving it to container.js file.
Probably we could also include the new admin setup into container file itself?
- Henry
On Thu, Sep 1, 2011 at 7:20 AM, Ryan J Baxter <rj...@us.ibm.com> wrote:
> 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: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>