Console icon indicating copy to clipboard operation
Console copied to clipboard

Powershell Script Access Issue in Sitecore SXA

Open RaghurajBiz opened this issue 2 years ago • 4 comments

Expected Behavior

User should get the read/write access after running AllowAccess Powershell Script.

_Please describe the expected behavior. _ User should get the read access.

Actual Behavior

User is not getting the read/write access after running AllowAccess Powershell Script. Please describe the actual behavior. limitation of the Add-ItemAcl command

Steps to Reproduce the Problem

Use case: We are considering two CMS users here that is user1 and user2. Both of these users belong to "DS Author" role which is a custom role basically means content author.

Step1 - User1 creates a microsite page in SXA called Page1 using PowerShell script. In this case read permission is denied for "DS Author" role on Page1 and read/write/create/delete permission allowed for user1 explicitly on Page1. In this way no other user belong to "DS Author" role will get access of Page1 except user1. Step2 - User1 can give read/write/create permission to user2 for Page1 using PowerShell script. Step3 - User1 can revoke access of Page1 using PowerShell script. In this case read permission is set to denied for page1 for user2 explicitly. Step4 - User1 can again give read/write/create permission to user2 for Page1 using PowerShell script which is mentioned in Step2.

In this case user1 is the owner of Page1 and he can give access or revoke access anytime to other users.

Now, we can see the Step4 is failing. That means when user1 gives access for the first time to user2 and then revoke access from user2 it is working fine. When user1 gives access again to user2 then it is not working.

When read access is set to denied for user2 once after that Sitecore is not setting it to allowed. This is the main issue we are facing. I am attaching PowerShell scripts for your reference. Please let me know the solution urgently for this as it is affecting our production site.

Other Information: We had raised the concern to sitecore support team and got the response saying since its 3rd party module they cannot provide support and redirected too here, There will be 2 access rights for the same user, one for AllowAccess and one for DenyAccess. In Sitecore, the deny access take precedence. Hence, User2 will not be able to read the item. This is limitation of the Add-ItemAcl command.

Example: $authorName = "user1" $micrositePath = "master:/content/BCG/Websites/Internal Information/DesignStudios/Home/Web platform/Client Proposal/Page1" Add-ItemAcl -Path $micrositePath -AccessRight item:read -PropagationType Any -SecurityPermission DenyAccess -Identity $authorName Add-ItemAcl -Path $micrositePath -AccessRight item:read -PropagationType Any -SecurityPermission AllowAccess -Identity $authorName

_Please include the version number of SPE and Sitecore.

  • [5.1 ] Tested issue with clean install of Sitecore and the latest available version of SPE.

RaghurajBiz avatar Apr 26 '23 11:04 RaghurajBiz

Can you add a screenshot showing the access on the item through each step?

michaellwest avatar Apr 26 '23 13:04 michaellwest

Hi Michaell,

Please find the Screenshot

Step 1: We will run the access rights to the User Access Item

Step 2: We will run the Revoke rights to the User Revoke Script

Step 3: Rerun the Script of Step 1 to give access to the same user.

It's getting failed to access the site whereas the user can't see read/write as per Sitecore support, the deny access take precedence. image

Please let me know if need any further information.

RaghurajBiz avatar Apr 26 '23 13:04 RaghurajBiz

I was hoping for a screenshot from the "Security Details" tab but the use of Get-ItemAcl is just as good. As you can see, the use of Add-ItemAcl is additive and therefore the Deny overrides the Allow.

Using Set-ItemAcl may be more appropriate for what you expect to happen.

michaellwest avatar Apr 26 '23 13:04 michaellwest

Hi @michaellwest,

We have checked the Set-ItemAcl option but it's overwriting the previous security information on an item. So, we cannot use it because we will have lot of Authors working on CMS and it will break the accessibility. of Authors for a specific item in the middle of their work.

Please help us in getting the solution for revoke/remove access for a respective user on any specific item.

Thanks, Raghu

RaghurajBiz avatar Apr 28 '23 07:04 RaghurajBiz

This issue is stale because it has been open for 365 days with no activity.

github-actions[bot] avatar May 12 '24 02:05 github-actions[bot]

@RaghurajBiz & @michaellwest I am not sure what the nature of this problem is.

After you use the Add-ItemAcl are they not added or are they added but do not exhibit the behavior you expected? If it's the former we need to fix it (although I could not reproduce it), if it's the latter then I would suggest that the security settings were not chosen correctly and there is another problem that is unrelated to this cmdlet or SPE in general.

Please confirm that the problem you're reporting is that Add-ItemAcl does not add the rights you've passed to it to the item and how we can reproduce it on a clean Sitecore (either with package or a script reproducing the situation).

Currently I have to assume that it works as intended based on the following script:

$authorName = "sitecore\admin"
$micrositePath = "master:/content/Home/security-test"
if(Test-Path $micrositePath){
    Remove-Item $micrositePath
}

New-Item $micrositePath -ItemType "Sample/Sample Item" | Out-Null

Write-Host "Before" -f Green

(Get-Item $micrositePath).Security.GetAccessRules()

Add-ItemAcl -Path $micrositePath -AccessRight item:read -PropagationType Any -SecurityPermission DenyAccess -Identity $authorName

Write-Host "After first assignment" -f Green
(Get-Item $micrositePath).Security.GetAccessRules()

Add-ItemAcl -Path $micrositePath -AccessRight item:read -PropagationType Any -SecurityPermission AllowAccess -Identity $authorName

Write-Host "After second assignment" -f Green
(Get-Item $micrositePath).Security.GetAccessRules()

The execution: image

Therefore closing the issue for now. Please reopen if you think this is wrong.

AdamNaj avatar May 20 '24 15:05 AdamNaj