[
https://issues.apache.org/jira/browse/JCR-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-4050:
------------------------
Resolution: Won't Fix
Status: Resolved (was: Patch Available)
i am sorry, but that request doesn't sound right to me. a consumer of the user
management API should neither know nor care about implementation details such
as how to create the pw hash.
and when it comes to the SLING repo-init: the original intention behind this
was the creation of service users which don't allow for having a password set
anyway. when it comes to regular users i first of all don't see too much
benefit in creating them with a repo-init within Sling. second it's sounds like
a pretty bad idea from a security pov that the person editing the repo-init
file would know and thus specify the password of any user. also this would
by-pass all password-constraints that might be required for a given repository
instance and which are enforced upon user creation or pw-change operations.
finally, it would mean that all repositories get the same password set for a
given user, which doesn't sound like a good idea to me... then the hashing is
the least problem you are having.
i would strongly recommend not to use the Sling repo-init for the setup of
regular users but stick with the original intention to use this for service
users only.
> Allow creation of users with existing password hashes in UserManager
> ---------------------------------------------------------------------
>
> Key: JCR-4050
> URL: https://issues.apache.org/jira/browse/JCR-4050
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api, jackrabbit-core, security
> Reporter: Jeffrey Bornemann
> Priority: Minor
>
> We utilize the UserManager API within Grabbit for syncing authorizable nodes
> between servers.
> Unfortunately, when it comes to syncing users, and specifically setting
> passwords from existing users; we have no public API facing way to create
> users with existing password hashes. We currently have to resort to using
> reflection, grabbing internal tree objects, and a bunch of nastiness that we
> would love to avoid with this change.
> Other consumers may also find this useful.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
