Ok, it's this part that was confusing me then, in UserManagerImpl.buildNodeId();
UUID uuid = UUID.nameUUIDFromBytes(id.toLowerCase().getBytes("UTF-8"));
Does the protected nature of jcr:uuid prevent me from changing the
userID by manually setting it to the value obtained from calling
UserManagerImpl.buildNodeId() with the new userID?
(Assume the principal was indeed set independently at creation time as
you suggest above, eg to a random uuid).
On Sat, Feb 9, 2013 at 12:58 AM, Angela Schreiber <anch...@adobe.com> wrote:
> hi torgeir
>
> it's that way for the UserManager implementations present in
> recent versions of jackrabbit core... but this isn't something that
> was mandated by the API.
>
> if you create a new user without explicitly specifying the
> principal the userID will be used for the principal name as
> well.
>
> in contrast, if you would call
>
> String id = "m...@mail.com";
> Principal principal = new PrincipalImpl("myprincipal");
> String intermediatePath = null;
> userManager.createUser(id, password, principal, intermediatePath)
>
> the resulting node would look something like
>
> jcr:uuid: 48442fdf-8cd0-3007-8af7-67059a5e1386
> rep:principalName: myprincipal
>
> and User#getPrincipal() would expose a principal whose name
> is "myprincipal". that was the name that gets stored into
> an ACE for that principal.
>
> if you are interested in the details, you may want to look at
> - UserManagerImpl#internalGetAuthorizable (line 880 ff)
> - UserManagerImpl#createAuthorizableNode (line 1398 ff)
>
> but changing the user's ID isn't possible out of the box.
>
> hope that helps
> angela
>
>
>
>
>
> On 2/8/13 3:05 PM, Torgeir Veimo wrote:
>>
>> Is this so for all UserManager implementations? I'm using
>> UserPerWorkspaceUserManager, as configured below. When I register a
>> user, using an email address for the first parameter (userID) to
>>
>> mail = "m...@mail.com";
>> userManager.createUser(mail, password);
>>
>> When I inspect the resulting rep:User node, then I see among other things;
>>
>> jcr:uuid: 48442fdf-8cd0-3007-8af7-67059a5e1386
>> rep:principalName: m...@mail.com
>> jcr:primaryType: rep:User
>>
>> It's only the mail address (userID) used for login purposes that I
>> need to be able to change.
>>
>> <UserManager
>> class="org.apache.jackrabbit.core.security.user.UserPerWorkspaceUserManager">
>> <param name="defaultDepth" value="1"/>
>> <param name="autoExpandTree" value="true"/>
>> <param name="autoExpandSize" value="100"/>
>> <param name="groupMembershipSplitSize" value="20"/>
>> <AuthorizableAction
>>
>> class="org.apache.jackrabbit.core.security.user.action.AccessControlAction">
>> <param name="groupPrivilegeNames" value="jcr:read"/>
>> <param name="userPrivilegeNames" value="jcr:all"/>
>> </AuthorizableAction>
>> </UserManager>
>>
>> On Fri, Feb 8, 2013 at 11:46 PM, Angela Schreiber<anch...@adobe.com>
>> wrote:
>>>
>>> hi torgeir
>>>
>>> the current implementation works as follows: the user's ID
>>> is in fact stored in the jcr:uuid property in order to
>>> have an efficient lookup upon Repository#login() such that
>>> UserManager#getAuthorizable(String id) basically doesn't
>>> require any kind of searching but as cheap as Session#getNodeByUUID().
>>> in addition the jcr:uuid is the only property that has
>>> a built-in mechanism to enforce uniqueness which is usually
>>> also desired when it comes to users.
>>>
>>> if you want to change the userID you'd have to change the
>>> uuid of the node such that the lookup userId -> jcr:uuid
>>> still works.
>>>
>>> in the access control content (to be precise in the rep:ACE
>>> nodes) the principal name is store. the user's ID doesn't
>>> have any relevance here. similarly it's only the Principal
>>> instances stored in the Subject that are used to enforce
>>> the permissions. populating the subject is the responsibility
>>> of the authentication process: either the subject is passed
>>> to the repo login using the java AccessControlContext or a
>>> new one is created and it is populated by the configured
>>> LoginModule(s) upon successful completion (LoginModule#commit).
>>>
>>> kind regards
>>> angela
>>>
>>>
>>> On 2/8/13 12:35 PM, Torgeir Veimo wrote:
>>>>
>>>>
>>>> Sorry I was a bit unclear. It's the username used for
>>>> repository.login() i need to change, so not the uuid. This is the
>>>> rep:principalName property?
>>>>
>>>> Is the rep:principalName used verbatim in ACLs etc? or is the rep:User
>>>> nodes' uuid used?
>>>>
>>>> On Fri, Feb 8, 2013 at 8:45 PM, Angela Schreiber<anch...@adobe.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> hi torgeir
>>>>>
>>>>> if you are referring to the userID: this can't be changed.
>>>>> moving/renaming a user node will only change the node name
>>>>> but the internal id used for the lookup (uuid) will not be
>>>>> affected.
>>>>>
>>>>> changing the principal name on the other hand would be a different
>>>>> story and has nothing to do with the userId. the principal
>>>>> name is the link to all the access control content for Principal
>>>>> represented by the given user.
>>>>>
>>>>> currently, the only way to change the userID while keeping
>>>>> the other user data was to create a new user and copy over
>>>>> the other information. the old user should be disabled.
>>>>>
>>>>> regards
>>>>> angela
>>>>>
>>>>>
>>>>> On 2/8/13 10:39 AM, Torgeir Veimo wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Is there a method to change the username of a jackrabbit managed user?
>>>>>>
>>>>>> Or is it the right way to change the rep:principalName property, along
>>>>>> with renaming and moving the rep:User node?
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> -Tor
>>
>>
>>
>>
>> --
>> -Tor
--
-Tor
