shindig-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jiraposter@reviews.apache.org (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SHINDIG-1601) Enhance Gadget Administration
Date Wed, 07 Sep 2011 00:27:12 GMT

    [ https://issues.apache.org/jira/browse/SHINDIG-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098501#comment-13098501
] 

jiraposter@reviews.apache.org commented on SHINDIG-1601:
--------------------------------------------------------



bq.  On 2011-09-06 21:13:01, johnfargo wrote:
bq.  > Hey Ryan,
bq.  > 
bq.  > The original intent of the <exports type="rpc">fooKey</exports> syntax
is that it is simply a declaration that the feature has in it somwhere:
bq.  > gadgets.rpc.register("fooKey", /* impl */);
bq.  > 
bq.  > As a corollary, <uses type="rpc">barKey</uses> means that there's a
code path that does gadgets.rpc.call("barKey", ...); Between these two, intelligent validation
and wiring could be done.
bq.  > 
bq.  > This comes with the caveat that the syntax hasn't actually been put to practice
yet, and real world utility trumps abstract thinking every time. This said, I do assert that
this syntax ought to be purely declarative, as part of a manifest describing the feature.
bq.  > 
bq.  > You could use the <uses> pieces to describe which rpc endpoints are _candidates_
for use by the gadget -- but I wouldn't use this for permissions, since those may differ container
by container.
bq.  > 
bq.  > --j

Awesome John this will work nicely.  I will be sure to use this in v2 of the patch.  

I am not going to use "uses" for permissions directly.  Basically the admin would specify
which features a gadget is allowed to you and based on that information we can infer the RPC
services the gadget calls by looking up the features in the features registry.  That list
can then be returned to container to try to arbitrate the RPC calls made by the gadget.  Based
on our other email thread it looks like we will only be able to arbitrate calls make from
the gadget to the container...


- Ryan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1666/#review1772
-----------------------------------------------------------


On 2011-08-26 16:05:12, Ryan Baxter wrote:
bq.  
bq.  -----------------------------------------------------------
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/1666/
bq.  -----------------------------------------------------------
bq.  
bq.  (Updated 2011-08-26 16:05:12)
bq.  
bq.  
bq.  Review request for shindig and johnfargo.
bq.  
bq.  
bq.  Summary
bq.  -------
bq.  
bq.  We want to allow administrators of containers to secure the features gadgets are allowed
to use. We can do this by doing two things to the container. 
bq.  
bq.  1.) When the gadget preloads a gadget and requests the iFrame URL for the gadget (indicating
the container wants to render the gadget) we check the list of allowed features for that gadget
in that container. In theory the administrator of the container would setup this list. If
the gadget wants to use a feature that is not in the list approved by the administrator the
preload fails. 
bq.  
bq.  2.) Secure what RPC service id a gadget can call. A gadget should only be able to call
the RPC service ids from the features the administrator has approved for that gadget in that
container. If the gadget tried to call and RPC service id that is not in a feature the administrator
has approved than the RPC call will be "blocked".
bq.  
bq.  THIS PATCH IS INCOMPLETE.  I just want to start to get feedback on this before I get
too deep and have to go back and change something major.  Currently this patch implements
number 1 above and part of number 2.  There no code yet to arbitrate the RPC calls, right
now this patch only returns the allowed RPC service IDs in the metadata request, but it doesn't
do anything with them.
bq.  
bq.  One of the major concerns I have is my use of <export type="rpc"..../> in the feature
XML files.  I am not sure if I am using them in the intended way.  Hoping John H can take
a look at that.
bq.  
bq.  
bq.  This addresses bug SHINDIG-1601.
bq.      https://issues.apache.org/jira/browse/SHINDIG-1601
bq.  
bq.  
bq.  Diffs
bq.  -----
bq.  
bq.    http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/servlet/GadgetsHandlerServiceTest.java
1157104 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/servlet/FakeProcessor.java
1157104 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/security/FeatureSecurityInfoTest.java
PRE-CREATION 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/security/ContainerSecurityInfoTest.java
PRE-CREATION 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/security/BasicFeatureSecurityStoreTest.java
PRE-CREATION 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/GadgetsHandlerApi.java
1157104 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/GadgetsHandlerService.java
1157104 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/security/FeatureSecurityModule.java
PRE-CREATION 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/security/FeatureSecurityStore.java
PRE-CREATION 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/features/FeatureRegistry.java
1157104 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/security/BasicFeatureSecurityStore.java
PRE-CREATION 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/pom.xml 1157104 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/DefaultGuiceModule.java
1157104 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/GadgetException.java
1157104 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/RenderingContext.java
1157104 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js
1157104 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/config/container.js 1157104 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/config/feature-security.json PRE-CREATION

bq.    http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/servlet/GadgetsHandlerTest.java
1157104 
bq.  
bq.  Diff: https://reviews.apache.org/r/1666/diff
bq.  
bq.  
bq.  Testing
bq.  -------
bq.  
bq.  Created/updated unit tests.
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Ryan
bq.  
bq.



> Enhance Gadget Administration
> -----------------------------
>
>                 Key: SHINDIG-1601
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-1601
>             Project: Shindig
>          Issue Type: New Feature
>    Affects Versions: 3.0.0
>            Reporter: Ryan Baxter
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> We want to allow administrators of containers to secure the features gadgets are allowed
to use.  We can do this by doing two things to the container.
> 1.)  When the gadget preloads a gadget and requests the iFrame URL for the gadget (indicating
the container wants to render the gadget) we check the list of allowed features for that gadget
in that container.  In theory the administrator of the container would setup this list.  If
the gadget wants to use a feature that is not in the list approved by the administrator the
preload fails.
> 2.)  Secure what RPC service id a gadget can call.  A gadget should only be able to call
the RPC service ids from the features the administrator has approved for that gadget in that
container.  If the gadget tried to call and RPC service id that is not in a feature the administrator
has approved than the RPC call will be "blocked".

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message