You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Brian McCullars <bd...@gmail.com> on 2012/02/15 04:15:07 UTC
Securing Gadget Features
Is there a way to add a custom feature to Shindig and only have specific
gadgets access that feature?
--
Brian McCullars
Mobile (513) 549-3099
Home (513) 549-5884
Re: Securing Gadget Features
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Yes so that was the second part of the work I did...RPC arbitration.
Essentially when RPC arbitration is enabled in the container.js the RPC
code arbitrate all RPC calls made to the container. If a gadget tried to
call an RPC service ID that is not used by any of the features it using
(both required and optional) than that RPC request will blocked. For
example if a gadget does not use the settitle feature but tries to make an
RPC call to the service id set_title it will be blocked.
To enable this , you need to set enableRpcArbitration to true in the
container.js
-Ryan
From: Brian McCullars <bd...@gmail.com>
To: dev@shindig.apache.org,
Cc: users@shindig.apache.org
Date: 02/15/2012 02:22 PM
Subject: Re: Securing Gadget Features
Thanks everyone for your help. One more question.
>From the JIRA below it is requesting the security be implemented on RPC
calls based on a service ID. So that a gadget can be put on whitelist, and
only that gadget can make the RPC call.
Has this been implemented as well in Shindig 3.0?
On Wed, Feb 15, 2012 at 9:25 AM, Ryan J Baxter <rj...@us.ibm.com>
wrote:
> Once slight clarification....
>
> If gadget administration is enabled and the gadget requires a feature it
> has not be allowed to use, the gadget render (and preload if you do it)
> will fail. If that same feature is declared to be optional in the
gadget
> definition than the javascript for that feature will not be loaded and
> gadgets.util.hasFeature(...) will return false if the gadget checks to
see
> if the feature is available.
>
> -Ryan
>
>
>
>
> From: Stanton Sievers/Westford/IBM@Lotus
> To: dev@shindig.apache.org,
> Cc: users@shindig.apache.org
> Date: 02/15/2012 07:24 AM
> Subject: Re: Securing Gadget Features
>
>
>
> Hi Brian,
>
> Gadget features can be secured via the gadget administration
functionality
>
> that was added to Shindig 3.0 a while back. Here's the JIRA:
> https://issues.apache.org/jira/browse/SHINDIG-1601
>
> This functionality is turned off by default and you would need to enable
> it in your container.js via gadgets.admin.enableFeatureAdministration.
The
>
> default configuration is handled in
> /shindig-project/config/gadget-admin.json and there's some sample data
in
> there.
>
> If gadget administration is enabled then at gadget load time the Shindig
> server won't serve up the JavaScript for a feature for a gadget unless
it
> is configured to allow it. If you want to dig around in the code you
can
> find the vast majority of it in the org.apache.shindig.gadgets.admin
> package in Shindig.
>
> -Stanton
>
>
>
> From: Henry Saputra <he...@gmail.com>
> To: dev@shindig.apache.org,
> Cc: users@shindig.apache.org
> Date: 02/14/2012 22:32
> Subject: Re: Securing Gadget Features
>
>
>
> Hi Brian,
>
> There is a way to add custom features to Shindig but I dont remember
> if there is an built-in mechanism to filter which gadgets could have
> access to that features.
>
> Any gadget definition could simply add <Require> or <Optional> to
> include features so I think the easiest way to prevent this is through
> your gadget registration flow?
>
>
> - Henry
>
> On Tue, Feb 14, 2012 at 7:15 PM, Brian McCullars <bd...@gmail.com>
> wrote:
> > Is there a way to add a custom feature to Shindig and only have
specific
> > gadgets access that feature?
> >
> > --
> > Brian McCullars
> > Mobile (513) 549-3099
> > Home (513) 549-5884
>
>
>
>
--
Brian McCullars
Mobile (513) 549-3099
Home (513) 549-5884
Re: Securing Gadget Features
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Yes so that was the second part of the work I did...RPC arbitration.
Essentially when RPC arbitration is enabled in the container.js the RPC
code arbitrate all RPC calls made to the container. If a gadget tried to
call an RPC service ID that is not used by any of the features it using
(both required and optional) than that RPC request will blocked. For
example if a gadget does not use the settitle feature but tries to make an
RPC call to the service id set_title it will be blocked.
To enable this , you need to set enableRpcArbitration to true in the
container.js
-Ryan
From: Brian McCullars <bd...@gmail.com>
To: dev@shindig.apache.org,
Cc: users@shindig.apache.org
Date: 02/15/2012 02:22 PM
Subject: Re: Securing Gadget Features
Thanks everyone for your help. One more question.
>From the JIRA below it is requesting the security be implemented on RPC
calls based on a service ID. So that a gadget can be put on whitelist, and
only that gadget can make the RPC call.
Has this been implemented as well in Shindig 3.0?
On Wed, Feb 15, 2012 at 9:25 AM, Ryan J Baxter <rj...@us.ibm.com>
wrote:
> Once slight clarification....
>
> If gadget administration is enabled and the gadget requires a feature it
> has not be allowed to use, the gadget render (and preload if you do it)
> will fail. If that same feature is declared to be optional in the
gadget
> definition than the javascript for that feature will not be loaded and
> gadgets.util.hasFeature(...) will return false if the gadget checks to
see
> if the feature is available.
>
> -Ryan
>
>
>
>
> From: Stanton Sievers/Westford/IBM@Lotus
> To: dev@shindig.apache.org,
> Cc: users@shindig.apache.org
> Date: 02/15/2012 07:24 AM
> Subject: Re: Securing Gadget Features
>
>
>
> Hi Brian,
>
> Gadget features can be secured via the gadget administration
functionality
>
> that was added to Shindig 3.0 a while back. Here's the JIRA:
> https://issues.apache.org/jira/browse/SHINDIG-1601
>
> This functionality is turned off by default and you would need to enable
> it in your container.js via gadgets.admin.enableFeatureAdministration.
The
>
> default configuration is handled in
> /shindig-project/config/gadget-admin.json and there's some sample data
in
> there.
>
> If gadget administration is enabled then at gadget load time the Shindig
> server won't serve up the JavaScript for a feature for a gadget unless
it
> is configured to allow it. If you want to dig around in the code you
can
> find the vast majority of it in the org.apache.shindig.gadgets.admin
> package in Shindig.
>
> -Stanton
>
>
>
> From: Henry Saputra <he...@gmail.com>
> To: dev@shindig.apache.org,
> Cc: users@shindig.apache.org
> Date: 02/14/2012 22:32
> Subject: Re: Securing Gadget Features
>
>
>
> Hi Brian,
>
> There is a way to add custom features to Shindig but I dont remember
> if there is an built-in mechanism to filter which gadgets could have
> access to that features.
>
> Any gadget definition could simply add <Require> or <Optional> to
> include features so I think the easiest way to prevent this is through
> your gadget registration flow?
>
>
> - Henry
>
> On Tue, Feb 14, 2012 at 7:15 PM, Brian McCullars <bd...@gmail.com>
> wrote:
> > Is there a way to add a custom feature to Shindig and only have
specific
> > gadgets access that feature?
> >
> > --
> > Brian McCullars
> > Mobile (513) 549-3099
> > Home (513) 549-5884
>
>
>
>
--
Brian McCullars
Mobile (513) 549-3099
Home (513) 549-5884
Re: Securing Gadget Features
Posted by Brian McCullars <bd...@gmail.com>.
Thanks everyone for your help. One more question.
>From the JIRA below it is requesting the security be implemented on RPC
calls based on a service ID. So that a gadget can be put on whitelist, and
only that gadget can make the RPC call.
Has this been implemented as well in Shindig 3.0?
On Wed, Feb 15, 2012 at 9:25 AM, Ryan J Baxter <rj...@us.ibm.com> wrote:
> Once slight clarification....
>
> If gadget administration is enabled and the gadget requires a feature it
> has not be allowed to use, the gadget render (and preload if you do it)
> will fail. If that same feature is declared to be optional in the gadget
> definition than the javascript for that feature will not be loaded and
> gadgets.util.hasFeature(...) will return false if the gadget checks to see
> if the feature is available.
>
> -Ryan
>
>
>
>
> From: Stanton Sievers/Westford/IBM@Lotus
> To: dev@shindig.apache.org,
> Cc: users@shindig.apache.org
> Date: 02/15/2012 07:24 AM
> Subject: Re: Securing Gadget Features
>
>
>
> Hi Brian,
>
> Gadget features can be secured via the gadget administration functionality
>
> that was added to Shindig 3.0 a while back. Here's the JIRA:
> https://issues.apache.org/jira/browse/SHINDIG-1601
>
> This functionality is turned off by default and you would need to enable
> it in your container.js via gadgets.admin.enableFeatureAdministration. The
>
> default configuration is handled in
> /shindig-project/config/gadget-admin.json and there's some sample data in
> there.
>
> If gadget administration is enabled then at gadget load time the Shindig
> server won't serve up the JavaScript for a feature for a gadget unless it
> is configured to allow it. If you want to dig around in the code you can
> find the vast majority of it in the org.apache.shindig.gadgets.admin
> package in Shindig.
>
> -Stanton
>
>
>
> From: Henry Saputra <he...@gmail.com>
> To: dev@shindig.apache.org,
> Cc: users@shindig.apache.org
> Date: 02/14/2012 22:32
> Subject: Re: Securing Gadget Features
>
>
>
> Hi Brian,
>
> There is a way to add custom features to Shindig but I dont remember
> if there is an built-in mechanism to filter which gadgets could have
> access to that features.
>
> Any gadget definition could simply add <Require> or <Optional> to
> include features so I think the easiest way to prevent this is through
> your gadget registration flow?
>
>
> - Henry
>
> On Tue, Feb 14, 2012 at 7:15 PM, Brian McCullars <bd...@gmail.com>
> wrote:
> > Is there a way to add a custom feature to Shindig and only have specific
> > gadgets access that feature?
> >
> > --
> > Brian McCullars
> > Mobile (513) 549-3099
> > Home (513) 549-5884
>
>
>
>
--
Brian McCullars
Mobile (513) 549-3099
Home (513) 549-5884
Re: Securing Gadget Features
Posted by Brian McCullars <bd...@gmail.com>.
Thanks everyone for your help. One more question.
>From the JIRA below it is requesting the security be implemented on RPC
calls based on a service ID. So that a gadget can be put on whitelist, and
only that gadget can make the RPC call.
Has this been implemented as well in Shindig 3.0?
On Wed, Feb 15, 2012 at 9:25 AM, Ryan J Baxter <rj...@us.ibm.com> wrote:
> Once slight clarification....
>
> If gadget administration is enabled and the gadget requires a feature it
> has not be allowed to use, the gadget render (and preload if you do it)
> will fail. If that same feature is declared to be optional in the gadget
> definition than the javascript for that feature will not be loaded and
> gadgets.util.hasFeature(...) will return false if the gadget checks to see
> if the feature is available.
>
> -Ryan
>
>
>
>
> From: Stanton Sievers/Westford/IBM@Lotus
> To: dev@shindig.apache.org,
> Cc: users@shindig.apache.org
> Date: 02/15/2012 07:24 AM
> Subject: Re: Securing Gadget Features
>
>
>
> Hi Brian,
>
> Gadget features can be secured via the gadget administration functionality
>
> that was added to Shindig 3.0 a while back. Here's the JIRA:
> https://issues.apache.org/jira/browse/SHINDIG-1601
>
> This functionality is turned off by default and you would need to enable
> it in your container.js via gadgets.admin.enableFeatureAdministration. The
>
> default configuration is handled in
> /shindig-project/config/gadget-admin.json and there's some sample data in
> there.
>
> If gadget administration is enabled then at gadget load time the Shindig
> server won't serve up the JavaScript for a feature for a gadget unless it
> is configured to allow it. If you want to dig around in the code you can
> find the vast majority of it in the org.apache.shindig.gadgets.admin
> package in Shindig.
>
> -Stanton
>
>
>
> From: Henry Saputra <he...@gmail.com>
> To: dev@shindig.apache.org,
> Cc: users@shindig.apache.org
> Date: 02/14/2012 22:32
> Subject: Re: Securing Gadget Features
>
>
>
> Hi Brian,
>
> There is a way to add custom features to Shindig but I dont remember
> if there is an built-in mechanism to filter which gadgets could have
> access to that features.
>
> Any gadget definition could simply add <Require> or <Optional> to
> include features so I think the easiest way to prevent this is through
> your gadget registration flow?
>
>
> - Henry
>
> On Tue, Feb 14, 2012 at 7:15 PM, Brian McCullars <bd...@gmail.com>
> wrote:
> > Is there a way to add a custom feature to Shindig and only have specific
> > gadgets access that feature?
> >
> > --
> > Brian McCullars
> > Mobile (513) 549-3099
> > Home (513) 549-5884
>
>
>
>
--
Brian McCullars
Mobile (513) 549-3099
Home (513) 549-5884
Re: Securing Gadget Features
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Once slight clarification....
If gadget administration is enabled and the gadget requires a feature it
has not be allowed to use, the gadget render (and preload if you do it)
will fail. If that same feature is declared to be optional in the gadget
definition than the javascript for that feature will not be loaded and
gadgets.util.hasFeature(...) will return false if the gadget checks to see
if the feature is available.
-Ryan
From: Stanton Sievers/Westford/IBM@Lotus
To: dev@shindig.apache.org,
Cc: users@shindig.apache.org
Date: 02/15/2012 07:24 AM
Subject: Re: Securing Gadget Features
Hi Brian,
Gadget features can be secured via the gadget administration functionality
that was added to Shindig 3.0 a while back. Here's the JIRA:
https://issues.apache.org/jira/browse/SHINDIG-1601
This functionality is turned off by default and you would need to enable
it in your container.js via gadgets.admin.enableFeatureAdministration. The
default configuration is handled in
/shindig-project/config/gadget-admin.json and there's some sample data in
there.
If gadget administration is enabled then at gadget load time the Shindig
server won't serve up the JavaScript for a feature for a gadget unless it
is configured to allow it. If you want to dig around in the code you can
find the vast majority of it in the org.apache.shindig.gadgets.admin
package in Shindig.
-Stanton
From: Henry Saputra <he...@gmail.com>
To: dev@shindig.apache.org,
Cc: users@shindig.apache.org
Date: 02/14/2012 22:32
Subject: Re: Securing Gadget Features
Hi Brian,
There is a way to add custom features to Shindig but I dont remember
if there is an built-in mechanism to filter which gadgets could have
access to that features.
Any gadget definition could simply add <Require> or <Optional> to
include features so I think the easiest way to prevent this is through
your gadget registration flow?
- Henry
On Tue, Feb 14, 2012 at 7:15 PM, Brian McCullars <bd...@gmail.com>
wrote:
> Is there a way to add a custom feature to Shindig and only have specific
> gadgets access that feature?
>
> --
> Brian McCullars
> Mobile (513) 549-3099
> Home (513) 549-5884
Re: Securing Gadget Features
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Once slight clarification....
If gadget administration is enabled and the gadget requires a feature it
has not be allowed to use, the gadget render (and preload if you do it)
will fail. If that same feature is declared to be optional in the gadget
definition than the javascript for that feature will not be loaded and
gadgets.util.hasFeature(...) will return false if the gadget checks to see
if the feature is available.
-Ryan
From: Stanton Sievers/Westford/IBM@Lotus
To: dev@shindig.apache.org,
Cc: users@shindig.apache.org
Date: 02/15/2012 07:24 AM
Subject: Re: Securing Gadget Features
Hi Brian,
Gadget features can be secured via the gadget administration functionality
that was added to Shindig 3.0 a while back. Here's the JIRA:
https://issues.apache.org/jira/browse/SHINDIG-1601
This functionality is turned off by default and you would need to enable
it in your container.js via gadgets.admin.enableFeatureAdministration. The
default configuration is handled in
/shindig-project/config/gadget-admin.json and there's some sample data in
there.
If gadget administration is enabled then at gadget load time the Shindig
server won't serve up the JavaScript for a feature for a gadget unless it
is configured to allow it. If you want to dig around in the code you can
find the vast majority of it in the org.apache.shindig.gadgets.admin
package in Shindig.
-Stanton
From: Henry Saputra <he...@gmail.com>
To: dev@shindig.apache.org,
Cc: users@shindig.apache.org
Date: 02/14/2012 22:32
Subject: Re: Securing Gadget Features
Hi Brian,
There is a way to add custom features to Shindig but I dont remember
if there is an built-in mechanism to filter which gadgets could have
access to that features.
Any gadget definition could simply add <Require> or <Optional> to
include features so I think the easiest way to prevent this is through
your gadget registration flow?
- Henry
On Tue, Feb 14, 2012 at 7:15 PM, Brian McCullars <bd...@gmail.com>
wrote:
> Is there a way to add a custom feature to Shindig and only have specific
> gadgets access that feature?
>
> --
> Brian McCullars
> Mobile (513) 549-3099
> Home (513) 549-5884
Re: Securing Gadget Features
Posted by Stanton Sievers <ss...@us.ibm.com>.
Hi Brian,
Gadget features can be secured via the gadget administration functionality
that was added to Shindig 3.0 a while back. Here's the JIRA:
https://issues.apache.org/jira/browse/SHINDIG-1601
This functionality is turned off by default and you would need to enable
it in your container.js via gadgets.admin.enableFeatureAdministration. The
default configuration is handled in
/shindig-project/config/gadget-admin.json and there's some sample data in
there.
If gadget administration is enabled then at gadget load time the Shindig
server won't serve up the JavaScript for a feature for a gadget unless it
is configured to allow it. If you want to dig around in the code you can
find the vast majority of it in the org.apache.shindig.gadgets.admin
package in Shindig.
-Stanton
From: Henry Saputra <he...@gmail.com>
To: dev@shindig.apache.org,
Cc: users@shindig.apache.org
Date: 02/14/2012 22:32
Subject: Re: Securing Gadget Features
Hi Brian,
There is a way to add custom features to Shindig but I dont remember
if there is an built-in mechanism to filter which gadgets could have
access to that features.
Any gadget definition could simply add <Require> or <Optional> to
include features so I think the easiest way to prevent this is through
your gadget registration flow?
- Henry
On Tue, Feb 14, 2012 at 7:15 PM, Brian McCullars <bd...@gmail.com>
wrote:
> Is there a way to add a custom feature to Shindig and only have specific
> gadgets access that feature?
>
> --
> Brian McCullars
> Mobile (513) 549-3099
> Home (513) 549-5884
Re: Securing Gadget Features
Posted by Stanton Sievers <ss...@us.ibm.com>.
Hi Brian,
Gadget features can be secured via the gadget administration functionality
that was added to Shindig 3.0 a while back. Here's the JIRA:
https://issues.apache.org/jira/browse/SHINDIG-1601
This functionality is turned off by default and you would need to enable
it in your container.js via gadgets.admin.enableFeatureAdministration. The
default configuration is handled in
/shindig-project/config/gadget-admin.json and there's some sample data in
there.
If gadget administration is enabled then at gadget load time the Shindig
server won't serve up the JavaScript for a feature for a gadget unless it
is configured to allow it. If you want to dig around in the code you can
find the vast majority of it in the org.apache.shindig.gadgets.admin
package in Shindig.
-Stanton
From: Henry Saputra <he...@gmail.com>
To: dev@shindig.apache.org,
Cc: users@shindig.apache.org
Date: 02/14/2012 22:32
Subject: Re: Securing Gadget Features
Hi Brian,
There is a way to add custom features to Shindig but I dont remember
if there is an built-in mechanism to filter which gadgets could have
access to that features.
Any gadget definition could simply add <Require> or <Optional> to
include features so I think the easiest way to prevent this is through
your gadget registration flow?
- Henry
On Tue, Feb 14, 2012 at 7:15 PM, Brian McCullars <bd...@gmail.com>
wrote:
> Is there a way to add a custom feature to Shindig and only have specific
> gadgets access that feature?
>
> --
> Brian McCullars
> Mobile (513) 549-3099
> Home (513) 549-5884
Re: Securing Gadget Features
Posted by Henry Saputra <he...@gmail.com>.
Hi Brian,
There is a way to add custom features to Shindig but I dont remember
if there is an built-in mechanism to filter which gadgets could have
access to that features.
Any gadget definition could simply add <Require> or <Optional> to
include features so I think the easiest way to prevent this is through
your gadget registration flow?
- Henry
On Tue, Feb 14, 2012 at 7:15 PM, Brian McCullars <bd...@gmail.com> wrote:
> Is there a way to add a custom feature to Shindig and only have specific
> gadgets access that feature?
>
> --
> Brian McCullars
> Mobile (513) 549-3099
> Home (513) 549-5884
Re: Securing Gadget Features
Posted by Henry Saputra <he...@gmail.com>.
Hi Brian,
There is a way to add custom features to Shindig but I dont remember
if there is an built-in mechanism to filter which gadgets could have
access to that features.
Any gadget definition could simply add <Require> or <Optional> to
include features so I think the easiest way to prevent this is through
your gadget registration flow?
- Henry
On Tue, Feb 14, 2012 at 7:15 PM, Brian McCullars <bd...@gmail.com> wrote:
> Is there a way to add a custom feature to Shindig and only have specific
> gadgets access that feature?
>
> --
> Brian McCullars
> Mobile (513) 549-3099
> Home (513) 549-5884