[jackrabbit-oak] branch feature/document-referential-integrity updated (d655e0e7f0 -> e70e908824)

[kw...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

kwin pushed a change to branch feature/document-referential-integrity
in repository https://gitbox.apache.org/repos/asf/jackrabbit-oak.git


    omit d655e0e7f0 Add paragraph on (non-existing) referential integrity of policies
     new e70e908824 OAK-10228: Explain effect of policies for unknown principals and non-existing paths

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

 * -- * -- B -- O -- O -- O   (d655e0e7f0)
            \
             N -- N -- N   refs/heads/feature/document-referential-integrity (e70e908824)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 .../site/markdown/security/accesscontrol/default.md | 21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

[jackrabbit-oak] 01/01: OAK-10228: Explain effect of policies for unknown principals and non-existing paths

[kw...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

kwin pushed a commit to branch feature/document-referential-integrity
in repository https://gitbox.apache.org/repos/asf/jackrabbit-oak.git

commit e70e90882494f63d35fa9dfcfcf7c880b2fa180d
Author: Konrad Windszus <kw...@apache.org>
AuthorDate: Fri Apr 28 15:22:58 2023 +0200

    OAK-10228: Explain effect of policies for unknown principals and
    non-existing paths
    
    Minor cleanup of markdown
---
 .../site/markdown/security/accesscontrol/default.md  | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/oak-doc/src/site/markdown/security/accesscontrol/default.md b/oak-doc/src/site/markdown/security/accesscontrol/default.md
index 3d046a6f5b..0dac3ffe40 100644
--- a/oak-doc/src/site/markdown/security/accesscontrol/default.md
+++ b/oak-doc/src/site/markdown/security/accesscontrol/default.md
@@ -128,6 +128,13 @@ found in section [Restriction Management](../authorization/restriction.html).
 
 <a name="representation"></a>
 
+#### Unknown Principals and Non-existing Paths
+
+Access control policies (or their entries) are bound to principals and JCR item paths. However, both must not necessarily exist: You can have policies for non-existing paths and/or unknown principals (i.e. referential integrity is not ensured). Deleting the referenced node or authorizable representing the principal won't have any effect in general.
+On the other hand, as the actual policies are persisted in the repository, they are removed whenever any of the parent nodes is removed (like any other regular child node).
+
+While importing access control policies via [JCR XML import](#xml-import) the behaviour for unknown principals can be configured.
+
 ### Representation in the Repository
 
 Access control policies created and modified using the default authorization model are stored as child of
@@ -167,9 +174,9 @@ the node they are bound to with name `rep:policy` or as node with path `/rep:rep
       - * (UNDEFINED) protected
       - * (UNDEFINED) protected multiple
 
-##### Examples
+#### Examples
 
-###### Regular ACL at /content
+##### Regular ACL at /content
 
     "": {
         "jcr:primaryType": "rep:root",
@@ -196,7 +203,7 @@ the node they are bound to with name `rep:policy` or as node with path `/rep:rep
         }
     }
 
-###### Repo-Level Policy
+##### Repo-Level Policy
 
     "": {
         "jcr:primaryType": "rep:root",
@@ -212,9 +219,10 @@ the node they are bound to with name `rep:policy` or as node with path `/rep:rep
     }
 
 <a name="xml_import"></a>
+
 ### XML Import
 
-As of OAK 1.0 access control content can be imported both with Session and
+As of Oak 1.0 access control content can be imported both with Session and
 Workspace import.
 
 In addition the JCR XML import behavior has been extended to respect the
@@ -239,6 +247,7 @@ the following entry:
 See also ([OAK-1350](https://issues.apache.org/jira/browse/OAK-1350)))
 
 <a name="validation"></a>
+
 ### Validation
 
 The consistency of this content structure is asserted by a dedicated `AccessControlValidator`.
@@ -262,6 +271,7 @@ The corresponding errors are all of type `AccessControl` with the following code
 
 
 <a name="configuration"></a>
+
 ### Configuration
 
 #### Configuration Parameters
@@ -275,7 +285,7 @@ The default implementation supports the following configuration parameters:
 | `PARAM_IMPORT_BEHAVIOR`      | String ("abort", "ignore", "besteffort") | "abort" |
 | | | |
 
-Differences to Jackrabbit 2.x:
+##### Differences to Jackrabbit 2.x:
 
 - The "omit-default-permission" configuration option present with the Jackrabbit's AccessControlProvider implementations is no longer supported with Oak.
 - As of OAK no extra access control content is installed by default which renders that flag superfluous.