CUG or closed user groups are the main way of restricting access to content. This is configured on a node that you require the user to have logged in to be able to view.
While it can be configured on any page in the sites.html console when a page is created by an editor, it can also be deployed with the content.
CUG
<?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:mix="http://www.jcp.org/jcr/mix/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" xmlns:rep="internal"
jcr:mixinTypes="[rep:AccessControllable]"
jcr:primaryType="cq:Page">
<jcr:content
cq:cugEnabled="true"
cq:cugLoginPage="/content/geometrixx-outdoors"
cq:cugPrincipals="screens-geometrixx-devices"
As you can see the information on the page's .content.xml reflects the same information available in sites.html and allows you to setup an area that is controlled by CUG. Any pages below the page that you restrict will also be restricted. One thing to note is that when you access a CUG controlled page If you are logged in and don't have the right access, you will get a 401 unauthorised error, however if you are not logged in you will be redirected to the CUG login page, or if you have put more advanced user access controls in place like SAML then they will take over the authorisation processes before returning the user to the required page.
Even though the user admin group shows access control, it is in fact just changing the ACL on the node itself, so you cannot deloy code for your group that has ACL's in it. in your code it will be in the file _rep_policy.xml
How you setup your ACL's is very dependent on the type of application you are building. For editorial sites the ACL's will be setup manually in either useradmin for groups or in sites.html for specific pages, non editorial fixed structure applications will want to deploy their ACL code with the application.
In the ui.apps section, we spoke about system users, the access requirements for a system user will need to be defined the same way as any group, by default they will have the same access as the everyone group.
<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:mix="http://www.jcp.org/jcr/mix/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" xmlns:rep="internal"
jcr:mixinTypes="[rep:AccessControllable]"
jcr:primaryType="cq:Page">
<jcr:content
cq:cugEnabled="true"
cq:cugLoginPage="/content/geometrixx-outdoors"
cq:cugPrincipals="screens-geometrixx-devices"
As you can see the information on the page's .content.xml reflects the same information available in sites.html and allows you to setup an area that is controlled by CUG. Any pages below the page that you restrict will also be restricted. One thing to note is that when you access a CUG controlled page If you are logged in and don't have the right access, you will get a 401 unauthorised error, however if you are not logged in you will be redirected to the CUG login page, or if you have put more advanced user access controls in place like SAML then they will take over the authorisation processes before returning the user to the required page.
In a single application, you can have more than one login page and different restrictions on each of the pages.
When you define a page as CUG controlled, AEM will remove any ACL's that were added to the page programmatically, or manually in crx/de and replace them with deny:everyone and allow: the groups selected
ACL
ACL (Access control) handling in AEM can be done manually in crx/de, in sites.html, useradmin, or via your code.
ACL (Access control) handling in AEM can be done manually in crx/de, in sites.html, useradmin, or via your code.
Sites
crx/de
User admin
Even though the user admin group shows access control, it is in fact just changing the ACL on the node itself, so you cannot deloy code for your group that has ACL's in it. in your code it will be in the file _rep_policy.xml
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:rep="internal"
jcr:primaryType="rep:ACL">
<deny
jcr:primaryType="rep:DenyACE"
rep:principalName="everyone"
rep:privileges="{Name}[jcr:read]"/> <allow
jcr:primaryType="rep:GrantACE"
rep:principalName="screens-geometrixx-devices"
rep:privileges="{Name}[jcr:read]"/> </jcr:root>
<jcr:root xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:rep="internal"
jcr:primaryType="rep:ACL">
<deny
jcr:primaryType="rep:DenyACE"
rep:principalName="everyone"
rep:privileges="{Name}[jcr:read]"/> <allow
jcr:primaryType="rep:GrantACE"
rep:principalName="screens-geometrixx-devices"
rep:privileges="{Name}[jcr:read]"/> </jcr:root>
How you setup your ACL's is very dependent on the type of application you are building. For editorial sites the ACL's will be setup manually in either useradmin for groups or in sites.html for specific pages, non editorial fixed structure applications will want to deploy their ACL code with the application.
In the ui.apps section, we spoke about system users, the access requirements for a system user will need to be defined the same way as any group, by default they will have the same access as the everyone group.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.