While users in AEM apps should not generally be deployed with the application, to build an application that modifies content via the code we should use a system user to access the content, and allow the correct access.
Users in AEM, while they appear in the jcr:content, they are not handled like normal nodes.
A System users node is in /home/users/system I do then tend to create an application folder for the users.
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:rep="internal"
jcr:primaryType="rep:SystemUser"
jcr:uuid="ebe5f4d0-2869-331a-ac51-8a70c909de7a"
rep:authorizableId="sample-service-user"
rep:principalName="sample-service-user"/>
As you can see the user node is pretty basic, however there are a few bits of important information
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0"
xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0"
jcr:primaryType="sling:OsgiConfig"
service.ranking="{Decimal}0"
user.mapping="[sample.core:service=sample-service-user]"/>
- rep:authorizableId
- The id that you would lookup the user in the authorisation api
- rep:principalName
- The principal name
- Should be the same as the authorizableId
- jcr:primaryType
- Defines that the user is a system user
- jcr:uuid
- The unique id for the user
- Can't be created manually
- Click User Administration which will popup a new window.
- Click Create System user and fill in the user id and the path you want the system user to be placed
- I will then create a package and export the user into my codebase so I can deploy it with my code
- You can configure your system user to be available to your code in the ui.apps configuration for the service user mapper
- org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-<app>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0"
xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0"
jcr:primaryType="sling:OsgiConfig"
service.ranking="{Decimal}0"
user.mapping="[sample.core:service=sample-service-user]"/>
You can create as many service users with different names as you like, the user mapping needs to be your java's package followed by the service name. I always create a service user, but sometimes I create multiple that will have access to different areas of the jcr:repository for different purposes. i.e. a workflow user, an activation user e.t.c
While you can create users in AEM and export them with your application, this is a very bad practice. I have created packages with users in the past for test users and deployed them on the test servers, but all end-users should be created manually in production systems.
Groups
Groups should also be created manually using the useradmin screen, once created they can be exported in the same way. All groups are stored in /home/groups and again I tend to create a subfolder for storing my application groups so that they are easy to find.
Groups should also be created manually using the useradmin screen, once created they can be exported in the same way. All groups are stored in /home/groups and again I tend to create a subfolder for storing my application groups so that they are easy to find.
Groups will always come with more than one file when it is exported, the main .content.xml file will be
<?xml version= "1.0" encoding= "UTF-8" ?>
<jcr:root xmlns:sling= "http://sling.apache.org/jcr/sling/1.0" xmlns:cq= "http://www.day.com/jcr/cq/1.0" xmlns:jcr= "http://www.jcp.org/jcr/1.0" xmlns:nt= "http://www.jcp.org/jcr/nt/1.0" xmlns:rep= "internal"
cq:lastModified= "{Date}2017-05-23T08:28:52.315Z"
cq:lastModifiedBy= "admin"
jcr:mixinTypes= "[rep:AccessControllable]"
jcr:primaryType= "rep:Group"
jcr:uuid= "e67c99a7-bbbd-3ae5-8cce-10f837eb29e2"
rep:authorizableId= "sample_acl"
rep:members= "{WeakReference}[2b792a03-6c6e-3c4c-b465-c8d128d102cb]"
rep:principalName= "sample_acl" >
<profile
jcr:primaryType= "nt:unstructured"
sling:resourceType= "cq/security/components/profile"
aboutMe= "Allow an author to set ACL settings"
givenName= "Sample ACL" /> </jcr:root>
<?xml version= "1.0" encoding= "UTF-8" ?>
<jcr:root xmlns:sling= "http://sling.apache.org/jcr/sling/1.0" xmlns:cq= "http://www.day.com/jcr/cq/1.0" xmlns:jcr= "http://www.jcp.org/jcr/1.0" xmlns:nt= "http://www.jcp.org/jcr/nt/1.0" xmlns:rep= "internal"
cq:lastModified= "{Date}2017-05-23T08:28:52.315Z"
cq:lastModifiedBy= "admin"
jcr:mixinTypes= "[rep:AccessControllable]"
jcr:primaryType= "rep:Group"
jcr:uuid= "e67c99a7-bbbd-3ae5-8cce-10f837eb29e2"
rep:authorizableId= "sample_acl"
rep:members= "{WeakReference}[2b792a03-6c6e-3c4c-b465-c8d128d102cb]"
rep:principalName= "sample_acl" >
<profile
jcr:primaryType= "nt:unstructured"
sling:resourceType= "cq/security/components/profile"
aboutMe= "Allow an author to set ACL settings"
givenName= "Sample ACL" /> </jcr:root>
Most of the data is very similar to the users data, however you have a few extra pieces
rep:members
This is a list of the members that are part of the group
Should not be exported in your code as the reference may not exist in your instance of AEM
Can be left if it refers to another group that is also being deployed at the same time
profile
Group profiles are not mandatory but give additional information about the group
aboutMe
The description of the group
givenName
The name of the group
If you go into useradmin and look at a user you will see that they can be part of many groups. The UI actually hides that the user has no reference to the group, but instead the group has a reference to the user, or other groups that are extending the rights of this group.
rep:members
This is a list of the members that are part of the group
Should not be exported in your code as the reference may not exist in your instance of AEM
Can be left if it refers to another group that is also being deployed at the same time
profile
Group profiles are not mandatory but give additional information about the group
aboutMe
The description of the group
givenName
The name of the group
If you go into useradmin and look at a user you will see that they can be part of many groups. The UI actually hides that the user has no reference to the group, but instead the group has a reference to the user, or other groups that are extending the rights of this group.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.