Angela Schreiber created SLING-9969:
---------------------------------------
Summary: SystemUsersEntryHandler contains hardcoded users home
path and doesn't include system-rel-path
Key: SLING-9969
URL: https://issues.apache.org/jira/browse/SLING-9969
Project: Sling
Issue Type: Bug
Components: Content-Package to Feature Model Converter
Reporter: Angela Schreiber
the constructor of {{SystemUsersEntryHandler}} looks as follows:
{code}
public SystemUsersEntryHandler() {
super("/jcr_root(/home/users/.*/)\\.content.xml");
}
{code}
i.e. it hardcodes the path to the users home node to the Adobe AEM specific
configuration. The default in Jackrabbit and Jackrabbit Oak is different (as
you can see in
http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/user/UserConstants.java?view=markup#l119).
instead of hardcoding the path it should be extracted from a configuration file
in order to make the converter independent of Adobe AEM.
in addition: oak comes with an addition configuration option that defines the
relative path below which all service users must be located (see
http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/user/UserConstants.java?view=markup#l141).
instead of traversing all user nodes (which may be quite a lot in a productive
enviroment), it would be better to fix the pattern such that it is limited to
the path, which is known to contain system users.
note: there is no validator in place that prevents other users from co-existing
with system users.... so verifying the primary type would still be needed, but
at least the system-user-handler would be limited to a usually fairly limited
sub-tree of the whole user store.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)