sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1581275 - /sling/site/trunk/content/documentation/bundles/resource-access-security.mdtext
Date Tue, 25 Mar 2014 08:32:00 GMT
Author: mykee
Date: Tue Mar 25 08:32:00 2014
New Revision: 1581275

CMS commit to sling by mykee


Modified: sling/site/trunk/content/documentation/bundles/resource-access-security.mdtext
--- sling/site/trunk/content/documentation/bundles/resource-access-security.mdtext (original)
+++ sling/site/trunk/content/documentation/bundles/resource-access-security.mdtext Tue Mar
25 08:32:00 2014
@@ -34,7 +34,7 @@ Furthermore the implementation of Resour
 The ResourceAccessGate defines a service API which can be used to make some restrictions
to accessing resources. Implementations of this service interface must be registered like
ResourceProvider with a path (like provider.roots but with the property name “path”).
If different ResourceAccessGate services match a path, not only the ResourceAccessGate with
the longest path will be called, but all of them, that's in contrast to the ResourceProvider,
but in this case more logical (and secure!). The access gates also must be registered with
a context (“application” or “provider”), without a given context, the
service will be ignored by ResourceAccessSecurity. The gates will be called in the order of
the service ranking. If one of the gates grants access for a given operation access will be
granted. An exception are the gates which are registered for “finaloperations”.
If such a gate denies resource access no further gate will be asked and access de
 nied (except a gate with higher service ranking has granted access).
-# Service properties
+### Service properties
 Property name     |  description
 ----------------- | ----------------------- 
@@ -43,7 +43,7 @@ operations        | set of operations on
 finaloperations   | set of operations on which the service answer is final and no further
service should be called (default none of them), except the GateResult is GateResult.CANT_DECIDE

 context           | “provider” or “application”. The resource access
gate can either have the context “provider”, in this case the gate is only applied
to resource providers requesting the security checks. Or the context can be “application”.
In this case the access gate is invoked for the whole resource tree. This is indicated by
the required service property “context”. If the property is missing or invalid,
the service is ignored.
-# How to implement ResourceAccessGate
+### How to implement ResourceAccessGate
 The implementation is straightforward. The easiest way is to extend ` AllowingResourceAccessGate
` which is exported by the resourceaccesssecurity bundle and does not deny any access. So
if you wan’t restrict access on resources for read operations you have to implement to
following two methods:
@@ -67,5 +67,5 @@ The implementation is straightforward. T
 And you have to register the ResourceAccessGate with the path where you wan’t to restrict
access and the operation property set to “read”. Furthermore you have to decide
if the ResourceAccessGate should operate on all resource providers (context=”application”)
or only on the resourceproviders flagged with the property useResourceAccessSecurity=true
-# Actual state of ResourceAccessSecurity
+## Actual state of ResourceAccessSecurity
 By now the implementation is complete for securing access on resource level for CRUD operations.
It is not yet ready to allow fine granular access rights on values of a resource. So at the
moment the `canReadValue, canUpdateValue, canDeleteValue` and `canCreateValue` on `ResourceAccessGate`
methods are ignored.
\ No newline at end of file

View raw message