This conversation has been locked due to inactivity. Please create a new post.
This conversation has been locked due to inactivity. Please create a new post.
Solved! Go to Solution.
Views
Replies
Total Likes
Please refer https://blogs.taylor-made-software.co.uk/aem/101/build/apps/users.html and Solved: Re: com.adobe.granite.security.user.UserProperties... - Adobe Experience League Community - ...
rep:Authorizable defines a new property rep:authorizableId which is intended to store the ID of a user or group.rep:authorizableId which asserts the uniqueness of that ID.jcr:uuid (protected and mandatory), which is used for the lookup.Authorizable#getID returns the string value contained in rep:authorizableID and for backwards compatibility falls back on the node name in case the rep:authorizableId property is missing.AuthorizableNodeName interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name.- rep:principalName (STRING) protected mandatory
- rep:authorizableId (STRING) protected /* @since oak 1.0 */
Please refer https://blogs.taylor-made-software.co.uk/aem/101/build/apps/users.html and Solved: Re: com.adobe.granite.security.user.UserProperties... - Adobe Experience League Community - ...
Please note the difference between Authorizable and Principal:
An Authorizable is repository object that is neither associated with nor depending from a particular Session and thus independent of the login mechanisms creating Sessions.
On the other hand Principals are representations of user identities. In other words: each Principal within the set associated with the Session's Subject upon login represents an identity for that user. An the set of Principals may differ between different login mechanisms.
Consequently an one-to-many relationship exists between Authorizable and Principal (see also getPrincipal().
Source -
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies