UnifiedSearch yields no results in WebApi

valdis

Vote:

Ok, this is pretty weird. When executing unified search in page controller context - it's working as expected (sample code):

public class SearchPageController : PageControllerBase<SearchPage>
{
    public ViewResult Index(SearchPage currentPage, string q)
    {
        var ctrl = new SearchController();
        var results = ctrl.Search(new SearchRequest { Query = q, PageSize = currentPage.ResultsCount });
        return View(new SearchPageViewModel(currentPage, q, results));
    }
}

WebApi controller:

public class SearchController : ApiController
{
    [HttpGet]
    public UnifiedSearchResults Search([FromUri] SearchRequest request)
    {
        var hitSpec = new HitSpecification
                      {
                          HighlightExcerpt = true,
                          ExcerptLength = 250,
                          PreTagForAllHighlights = "<strong><em>",
                          PostTagForAllHighlights = "</em></strong>"
                      };

        var results = SearchClient.Instance.UnifiedSearchFor(request.Query)
            .TermsFacetFor(p => p.SearchSection)
            .Skip(request.Page * request.PageSize)
            .Take(request.PageSize)
            .GetResult(hitSpec);

        return results;
    }
}

When accessing WebApi directly from client-side the same method it yields zero results (SearchRequest parameter in WebApi *is* binded correctly):

$.getJSON('/Api/Search/Search', { Query: q.val(), Page: 1, PageSize: 10 }, function (data) {
    alert(data);
});

#74013

Aug 17, 2013 9:38

Frederik Vig

Vote:

What is the value of results when using ajax to call it?

#74015

Aug 17, 2013 11:15

valdis

Vote:

Result is [].

Results are empty already on server side.

#74017

Aug 17, 2013 17:59

Frederik Vig

Vote:

Same behavior if you make the call using the HttpClient class instead of instansiating the SearchController in SearchPageController´s Index method?

#74020

Aug 18, 2013 13:55

Henrik Lindström

Vote:

Hi Valdis,

I might guess that your problem is the skip/take. Your API call will set skip = 10 and Take = 10 meaning that you fetch page 11 to 20. If you set Page = 0 you will get the first 10 pages.

Regards,

Henrik

#74025

Aug 19, 2013 9:27

valdis

Vote:

I can confirm that there is more than 50 hits. It's the case even without any paging. I'll try to compare packages sent to Find..

#74027

Aug 19, 2013 10:01

Andreas Nicolaisen

Vote:

Did you find any solution to this. It seems that we have the same problem. GetFilesResult and GetResult for pages gives results, but when I use UnifiedSearchFor, no results gets returned.

The code I use for UnifiedSearchFor looks like this (using a query that yields results in the two other cases as mentioned):

ITypeSearch<ISearchContent> search = SearchClient.Instance.UnifiedSearchFor(query, Language.Norwegian);
UnifiedSearchResults res = search.GetResult();

#74529

Aug 30, 2013 12:44

Joel Abrahamsson

Vote:

Could you check the optional parameters for the GetResult method and try to set the one for filtering for public display (or something like that) to false? I find it hard to believe, but it may be related to the access rights filtering.

#74532

Aug 30, 2013 13:15

Andreas Nicolaisen

Vote:

That did the trick Joel.

i.e, the code now looks like this and gives results:

ITypeSearch<ISearchContent> search = SearchClient.Instance.UnifiedSearchFor(query, Language.Norwegian);
UnifiedSearchResults res = search.GetResult(new HitSpecification(), false);

#74533

Edited, Aug 30, 2013 13:33

Joel Abrahamsson

Vote:

Cool, but now unpublished content or content that a public visitor doesn't have read access to may appear in the result. I'm not entirely sure how to fix that as it depends on how CurrentPrincipal works.

#74534

Aug 30, 2013 13:35

valdis

Vote:

You know, my story is a bit different :) Without any changes either in code, index content or anything elsewhere - it started to give results back. I believe that this could be related with something happened on find service side.

#74550

Aug 31, 2013 13:15

Øyvind

Vote:

I suspect this to be a bug in EPiServer Find when specifying a language (which we are still experiencing...)

In our case we have an index for Norwegian and English. English works as expected, but when specifying Norwegian (either in UnifiedSearchFor-method, or FilterOnLanguages) we always get zero hits.

I've investigated this in Fiddler, and it seems like Language.Name$$string is always set to "en" no matter which language we specify.

The workaround suggested by Joel, works fine - but as stated, this also returns all hits even if the current user doesn't have access to them (by access control or publish status).

Has anyone found a good solution to this ?

#122347

May 31, 2015 23:58

Henrik Lindström

Vote:

UnifiedSearch will by default filter on your current language branch. If you want to override this behaviour you have to use:

.OverrideCurrentLanguage("sv")

/Henrik

#122437

Jun 02, 2015 15:46

Vincent

Vote:

I also came to this problem in my current Commerce project (all my products are visible to everyone) and Joel's suggestion worked like a charm. However, as he said it would cause unpublished contents showing in the search results. Is it still a bug in EPi find?

 public UnifiedSearchResults SiteSearch(string keybowrd)
        {            
            return _client.UnifiedSearchFor(keybowrd)
                .UsingAutoBoost()   
                .Track()
                .Take(100)     
// *** GetResult() came back with empty results.   ****
                .GetResult(new HitSpecification(),false);
        }

Latest version Commerce + Find

#144651

Edited, Feb 17, 2016 2:53

Vegard Helland

Vote:

If you have any kind of OWin initialization in your project, e.g. the ServiceApi or LiveMonitor, CurrentPrincipal in a WebApi call will not be set unless this is specified somewhere. Try setting CurrentPrincipal like this in the Web Api:

IPrincipal principal = new GenericPrincipal(
    new GenericIdentity("myuser"), new string[] { "myrole" });
Thread.CurrentPrincipal = principal;
HttpContext.Current.User = principal;

If that works, you can move forward with proper propagation of CurrentPrincipal based on client authentication.

#144658

Feb 17, 2016 7:55

Vincent

Vote:

I used this method in the cms controller, it should not be the concern. Secondly, is the unifiedsearch designed for site wide search? If yes, then why do i need to pass the principle to the method? In addition, if i used search method, with filter access , the expected results came back. Confuse....

#144675

Feb 17, 2016 11:29

Henrik Lindström

Vote:

UnifiedSearch will (when having filter for public search set to 'true') filter by published content visible to the user in the current language and by current site. As for user and language it will fallback on 'all' if not set but as for site it will only show content visible to all sites if not set (in a multisite setup content can be part of either one of the sites or all of them. Here 'all' isn't all sites but rater shared content between all sites). If your site only contains content from one site it will then be filtered out completly if 'SiteDefinition.Current.Id'SiteDefinition.Current.Id' is not set. However if you wan't it to always search cross all sites you can update your public search filter and only filter on language and user:

client.Conventions.UnifiedSearchRegistry
.ForInstanceOf<PageData>()
.PublicSearchFilter((c, ctx) => c.BuildFilter<IContentData>()
.FilterForVisitor(ctx.Language == null || ctx.Language == Language.None
? Languages.AllLanguagesSuffix
: ctx.Language.FieldSuffix)
.ExcludeContainerPages()
.ExcludeContentFolders());

/Henrik

#144737

Feb 18, 2016 11:04

Vincent

Vote:

Thanks everyone for your help.

The issue has been fixed by removing the "EPiServer.Find.Cms" using statement, I have no idea why my brain triggered me doing this, though I am still not clear what happened.

using System.Collections.Generic;
using System.Linq;
using System.Web.Mvc;
using EPiServer;
using EPiServer.Core;
using EPiServer.Framework.DataAnnotations;
using EPiServer.Web.Mvc;
using Website.Models.Pages;
using EPiServer.Find.Framework;
/*
using EPiServer.Find.Cms;

Without this using statement, unifiedsearch works as expected.
*/ 

using EPiServer.Find;
using System.Threading;
namespace Website.Controllers
{
    public class StartPageController : PageController<StartPage>
    {
        public ActionResult Index(StartPage currentPage)
        {
            /* Implementation of action. You can create your own view model class that you pass to the view or
             * you can pass the page type for simpler templates */

            var results = SearchClient.Instance.UnifiedSearchFor("a").GetResult();

            var principal = Thread.CurrentPrincipal;

            return View(currentPage);
        }
    }
}

Can someone help to explain what happened behind the sense?

Regards,

Vincent

#144898

Feb 22, 2016 12:15

Vincent

Vote:

Support team said it's likely a bug. The issue has been logged into the system.

#145162

Feb 26, 2016 0:51

ngibbons

Vote:

Wow - thank god I found this.

The same thing worked for me - removing the using statement - crazy!

#145575

Mar 07, 2016 12:42

Alex Holland

Vote:

Just hit this problem when updating a client site from 7.19 to 8.11 (to fix the Chrome 67 edit bug - alas, we don't have approval to take it all the way to EPi 11).

What I found:

UnifiedSearch worked fine IF no Filters were applied to the query. As soon as one filter was applied, even if it was .MatchTypeHierarchy(typeof(PageData)), I would get no results.
Removing the EPiServer.Find.CMS namespace didn't fix this for me (and we need it for some of our advanced filters)
Joel's suggestion of setting filterForPublicSearch = false when calling GetResults did work, but obviously this then shows content which should be restricted.

My solution was to shift the filterForPublicSearch behaviour into my query, then call GetResults with filterForPublicSearch set to false. Eventually worked out the easiest way to do this was to add a convention to my Find Initialization module:

SearchClient.Instance.Conventions.UnifiedSearchRegistry
	.Add<IContentSecurable>()
	.AlwaysApplyFilter(c => c.BuildFilter<IContentSecurable>()
		.And(content => content.RolesWithReadAccess().Match("Everyone")));

(adapted from http://world.episerver.com/Forum/Developer-forum/EPiServer-Search/Thread-Container/2013/6/Unified-Search---Excluding-pages-by-property/)

This seems to do the trick, and gets me the same results as I had in EPiServer 7.19.

Was the root cause of this ever discovered/fixed, and in which version? It would be useful to add a comment for future developers, but I can't find any bug tickets which refer to this. I appreciate UnifiedSearch seems to be a bit of a niche concern these days.

#195056

Edited, Jul 12, 2018 10:51