Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

Closed User Group (CUG) not working as expected and allowing all users to login

Avatar

Level 3
 
 

I am testing out Closed User Group (CUG). I followed basic steps for adding CUG for a page (https://experienceleague.adobe.com/docs/experience-manager-64/administering/security/cug.html#securi...). After following the steps, it adds restrictions to the page and requires login to the page as expected. However, it allows every valid users to login in the page. 

 

To elaborate, if I have group G1 having user U1 part of group and add G1 under Closed User Group from page properties, it should only allow U1 to login to the restricted page. However, it allows other users (U2, U3 for example) as well to access CUG restricted page which is not an expected scenario. To summarize, it allows all valid users to login to the CUG restricted page. To add, I am testing from publisher side, so no dispatcher changes would come into affect here. 

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Level 3

Adding my update for the issue for someone who visits this.

So, CUG will allow the users (U2, U3) to login and will not send error response for "authentication". And it will set the login-token cookie. However, since the user is not authorized to view the content for the page, it will show up 404 page. In your case, if you have setup a default 404 page, it will show up content from that page after setting the login-token cookie. Now since the default 404 page content might be part of /apps/<your-site>, you will need to give read permission (to U2 and U3, make sure you don't mess up ACLs on publishers) to that path as well (pretty much the issue I had where the 404 page content was not being rendered properly). 

To summarize, even if the user is not "authorized" to view the content since it is not part of group G1, it will set the login-token cookie but render 404 page. If the user is part of group G1, it will show up the content of the page. I had all the required permissions set from /content/ but read permission under /apps/<site> were missing which is holding some default designs.

View solution in original post

3 Replies

Avatar

Community Advisor

Hi @chintan97patel,

Could you please share the level of permissions for U2 and U3 and its groups, if any associated to the same.

Also, just as an additional check, cross check the CUG group and its users/permissions from being in Publish instance. 

 

Avatar

Community Advisor

Hi,

Can you please confirm:

  • Page has only one group(G1), you can varify from crxde as wll the principals stored in rep:cugPolicy node
  • User U2 and U3 does not have any group(or at least Group G1)
  • anonymous user can't access the protected page as well


Arun Patidar

Avatar

Correct answer by
Level 3

Adding my update for the issue for someone who visits this.

So, CUG will allow the users (U2, U3) to login and will not send error response for "authentication". And it will set the login-token cookie. However, since the user is not authorized to view the content for the page, it will show up 404 page. In your case, if you have setup a default 404 page, it will show up content from that page after setting the login-token cookie. Now since the default 404 page content might be part of /apps/<your-site>, you will need to give read permission (to U2 and U3, make sure you don't mess up ACLs on publishers) to that path as well (pretty much the issue I had where the 404 page content was not being rendered properly). 

To summarize, even if the user is not "authorized" to view the content since it is not part of group G1, it will set the login-token cookie but render 404 page. If the user is part of group G1, it will show up the content of the page. I had all the required permissions set from /content/ but read permission under /apps/<site> were missing which is holding some default designs.