Sp-starter-kit: Redirect web part fails if there are specific permissions on list items

[metkhoo]

Category

• [x] Bug

Describe the bug

The Redirect extension works correctly when both the "PnP Redirect Links" list and list items therein do not have their permissions modified.
When list items have specific permissions (i.e. breaking inheritance and applying specific permissions to list items) then the Redirect extension fails.

Expected or Desired Behavior

Expected that the Redirect continues to work even with specific list item security.

Observed Behavior

Redirect fails with console message "Failed to create custom list PnP Redirect Links" when item level security is applied.

Steps to Reproduce

Install the Redirect extension and let it create the custom list.
Create two list items, each with same source URL and different destination URL's
Go to the source URL - Redirects correctly on the first "found" item.

Now, stop inheriting permissions on each item and only allow members of specific groups to see the list items.
When user logs in they can navigate to the custom list and they will only see ONE of the two items.

Redirect now fails with console message "Failed to create custom list PnP Redirect Links"

NOTE: I have determined that the bug appears to be in the this line:

       const ensureResult: ListEnsureResult = await sp.web.lists.ensure(redirectionsListTitle,
       'Redirections',
        100,
        true);

The "ensure" method fails, even though the list exists for the user.

My workaround is to
a) allow the default extension to create the list in the first place
b) replace line 67

   if (await this.ensureRedirectionsList(redirectionsListTitle)) 

with

   if (true)

then build a new version of the extension
then deploy the extension

Environment Details (Development & Target environment)

SharePoint online

[msftbot[bot]]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[bcameron1231]

Since you have broken inheritence, can you confirm whether the users have access on the list level for READ, and not just the list item? It seems like the user may not have permission on the list and only on the items, which could be causing the ensure to fail and try to create a list instead.

[metkhoo]

Hi and thanks for picking this up.

To confirm, users do have "Read" access to the list (Inheritance is not broken at list level - only at item level).
If I login as a user then they can see the list and open the list.
A user will see their single list item.
A site admin will see all the items in the list.

[bcameron1231]

Thank you. I have looked into this a bit further, apologies for the delay. It appears the ensure() method requires elevated permissions, as users with READ permissions cannot use the Ensure() method.

We will need to update the code and remove and/or update the ensure method logic to better establish the existence of the list.

[bcameron1231]

@eoverfield - I am going to put in a fix for this. As above, a user with "read" permission is unable to call the ensure() function. Question for you:

Would you prefer we...

1. Simplify the code and make an assumption that the list exists and is accurate (remove ensure())
2. Put in more logic to determine whether the current user can call the ensure() method, this could still result in a 404 for end users with Read.

My preference would be option a - to remove the ensure all together, given that if the list isn't set up correctly in the first place, a read user would still be unable to redirect.

UPDATED - Actually, this would also require an update to the provisioning template to include the ListInstance, as we are utilizing the Ensure() method to make sure the list is provisioned.... so I am going to put in a fix, that calls the Ensure, but subsequently would call the GET regardless.