1
votes

I am using Sitecore 7.5 and SOLR 4.7 and I am noticing that the TotalSearchResults property seems to ignore item security.

I perform a search, skip to the proper page and only take the amount needed for the page and the TotalSearchResults value is 31. However the Results themselves are zero (which is correct).

In my Sitecore implementation there are 31 matches for the search, but all of them are restricted by security and should not be accessible by the anonymous user. Is this right? I feel like I am missing something.

public static SearchResults<myCustomSearchResultItem> SearchContent(string searchTerm, int currentPage, int pageSize, string indexName) {
  using (var context = ContentSearchManager.GetIndex(indexName).CreateSearchContext(SearchSecurityOptions.EnableSecurityCheck)) {
  var query = context.GetQueryable<GeneralSearchResultItem>()
                     .Where(x.Language == Sitecore.Context.Language.Name);
  query = query.Where(i => (i.Content.Contains(searchTerm) || i.Name.Contains(searchTerm)));

  //Paging
  if (currentPage > 1) {
    query = query.Skip((currentPage - 1) * pageSize);
  }

  query = query.Take(pageSize);
  return query.GetResults();
  }
}

When I run the above code I get the following:

myResults.TotalSearchResults = 31
myResults.Count() = 0

The correct results should be zero items returned because all of the items are security restricted. So myResults.Count() = 0 is correct. However the TotalSearchResults = 31 is wrong.

Does TotalSearchResults ignore Sitecore security?

1

1 Answers

0
votes

TotalSearchResults return whatever items count kept from the index actually satisfy your query. If both security-protected and free items are within index - then it will operate against that set (and I think that is what you are getting). No security data comes into indexes by default.

What does matter indeed - is the actual way how you do index items and what you place there. You may consider from the following options to fit your case:

  1. Avoid placing security-protected items at all (not the best scenario)

  2. Placing both free and items with additional security data (you may specify in computed field, for example) and add additional clause to filter and select only free items. You may consider index a field from Standard Template called __Security that has pipe separated security settings for that item

  3. Include (external, not from index) security check into your Linq query as an additional clause (leaving index untouched itself as is), but that does not seem nice from performance point of view and need to think well big numbers cases (unlike previous point where security stored in the index and resolved by Lucene query)