Is there any way to show Post Security Timming results without having display “gaps”?

Question

We have implemented post security trimming on a SharePoint 2013 search site and it works fine, except for the very odd display - if I do a Search without trimming on, it will show 10 results per page and page as normal using the numbered page links at the bottom of the page.

If I do a search with post security trimming on, it will show maybe 1 result on the first page, 1 results on the second page, 2 results on the 3rd page, etc, etc depending on what has been trimmed - almost like the results that are denied by the trimming are hidden but still count towards the 10 results per page. This seems a really odd way to do it and I'm very surprised this is out of the box functionality.

Does anyone know of a way to show all the trimmed results together so the results look "normal"? I did think of maybe removing items from the documentUrls IList used in the CheckAccess method but I'm not sure this is even possible or would produce the required results. Is there a parameter I need to see on the search results webpart or in the CheckAccess call?

Thanks for your help!

Answer 1

It appears that SharePoint 2013 changed the behaviour of security trimming and pagination at some point. I believe that the pagination is now calculated BEFORE trimming occurs, then items on the page are removed via the trimmer. This process naturally leads to gaps on the page (security trimmed results).

• This is certainly not expected behaviour from a user's standpoint
• This behaviour didn't occur in SharePoint 2010 (eg the behaviour has changed)

For these reasons I believe it's a bug / defect in SharePoint that's been accidentally introduced at some point, possibly as a result of another bugfix that's gone awry.

At this juncture I don't believe it's possible to fix (via a workaround) the pagination issues that you're seeing unless you implement your own back-end service that properly calculates page counts AFTER trimming occurs. I would be inclined to raise it as a bug / defect with Microsoft, as we are.