This has been fixed in the Jackrabbit 1.6.0 onwards.
Do we want to upgrade, I cant remember the back compatibility issues
with 1.6 ?
(I have a modified ACLTemplate so I don't need to, but if this hits
others, then it might make sense)
Ian
On 1 Nov 2009, at 16:26, Ian Boston wrote:
If you add a user with the user manager, create a node, add an acl
that references the user, then remove the use from the user manager,
the following happens.
What is not entirely clear is the impact of this. Either the ACL
fails to get compiled and access to the node is denied, or, the
exception is caught somewhere and the statement gets ignored.
AFAICT, when this happens, loading the ACL template stops being
processed ignoring all later entries and access to the node is
denied altogether, meaning that if any principals are ever removed
from a JCR, any nodes where there are ACLs either granted or denied
become instantly inaccessible to all users.
Does that sound like a correct analysis ?
Whats the right course of action, never remove a user from the
system ?
Patch the ACLTemplate to ignore NoSuchPrincipalExceptions ?
Find all ACLs that contain the principal and remove them ?
BTW, the last one may be imparctical where a PrincipalManager looks
at an external system. IMHO the best solution is going to be "Patch
the ACLTemplate to ignore NoSuchPrincipalExceptions " but thats
Jackrabbit code, not Sling ?
Ian
1.11.2009 16:11:29.951 *ERROR* [127.0.0.1 [1257091889782] GET /
_user.infinity.json HTTP/1.1]
org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource
listChildren: Cannot get children of JcrNodeResource,
type=sling:Folder, superType=null, path=/_user/private/01/32/cf/2d
org
.apache.jackrabbit.api.security.principal.NoSuchPrincipalException:
Unknown principal user1-1257091867
at
org
.apache
.jackrabbit
.core
.security
.principal
.PrincipalManagerImpl.getPrincipal(PrincipalManagerImpl.java:75)
at
org
.apache
.sling
.jcr
.jackrabbit
.server.impl.security.standard.ACLTemplate.<init>(ACLTemplate.java:
113)
at
org
.apache
.sling
.jcr
.jackrabbit
.server.impl.security.standard.ACLEditor.getACL(ACLEditor.java:92)
at
org
.apache
.sling.jcr.jackrabbit.server.impl.security.standard.ACLProvider
$AclPermissions.buildResult(ACLProvider.java:586)
at
org
.apache
.jackrabbit
.core
.security
.authorization
.AbstractCompiledPermissions
.getResult(AbstractCompiledPermissions.java:46)
at
org
.apache
.jackrabbit
.core
.security
.authorization
.AbstractCompiledPermissions.grants(AbstractCompiledPermissions.java:
82)
at
org
.apache
.sling.jcr.jackrabbit.server.impl.security.standard.ACLProvider
$AclPermissions.grants(ACLProvider.java:673)
at
org
.apache
.jackrabbit
.core
.security.DefaultAccessManager.isGranted(DefaultAccessManager.java:
232)
at
org
.apache
.jackrabbit
.core
.security.DefaultAccessManager.isGranted(DefaultAccessManager.java:
220)
at org.apache.jackrabbit.core.ItemManager.canRead(ItemManager.java:
339)
at
org
.apache.jackrabbit.core.ItemManager.hasChildNodes(ItemManager.java:
567)
at org.apache.jackrabbit.core.NodeImpl.hasNodes(NodeImpl.java:2710)
at
org
.apache
.sling
.jcr
.resource
.internal
.helper.jcr.JcrNodeResource.listChildren(JcrNodeResource.java:237)
at
org
.apache
.sling
.jcr
.resource
.internal
.helper
.jcr.JcrResourceProvider.listChildren(JcrResourceProvider.java:107)
at
org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry
$1.seek(ResourceProviderEntry.java:180)
at
org.apache.sling.jcr.resource.internal.helper.ResourceProviderEntry
$1.<init>(ResourceProviderEntry.java:154)
at
org
.apache
.sling
.jcr
.resource
.internal
.helper
.ResourceProviderEntry.listChildren(ResourceProviderEntry.java:126)
