[
https://issues.apache.org/jira/browse/SHINDIG-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098501#comment-13098501
]
[email protected] 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
