Is it right, that the folling will yet fail, because the nodes and properties
of the security workspace are not directly modifiable?
not quite... the security workspace isn't any different to the other
workspaces. once you obtained a session for that workspace you
can modify items according to the general rules defined by the JCR
API which include that protected items may not be modified using
the general jcr write methods.
the idea of the security workspace was to keep user information only
once for the whole repository. i other words: all workspaces retrieve
the user information from that dedicated workspace.
and one more comment: there is also an alternative implementation keeps
the user/group information in each workspace.
-> see UserPerWorkspaceSecurityManager.
Authorizable a = um.getAuthorizable(userId);
boolean result = a.hasProperty("rep:principalName");
which results to false.
Authorizable.hasProperty isn't the same as Node.hasProperty.
you could write an UserManagement implementation that doesn't
store users in the repository. it's an implementation detail
that the users pw is stored in a JCR property. the authoriable
properties are meant to be used for additional custom user
attributes... e.g. a display name.
regards
angela
