REST API поиска SharePoint с токеном-носителем возвращает неверное количество элементов - PullRequest
Новая
       16

REST API поиска SharePoint с токеном-носителем возвращает неверное количество элементов

2 голосов
/ 09 мая 2019

У меня ОЧЕНЬ странная проблема с поиском.Я делаю запрос, используя GET для https://sonar-sandbox.gredspdev.loc/_api/search/query?querytext='DMSSonarDocId:5042aa1f-b3a4-4577-8e21-8a47ca27c243 OR DMSSonarDocId:1401144b-bd3d-429a-a386-5061ecc714e1'&sourceid='a0f4d450-e701-4f2a-888a-8d871002752d'&trimduplicates=false&rankingmodelid='05289DBE-73E9-4665-BF69-EE68274176EB'&rowlimit=9000&enablestemming=false&enablesorting=false&selectproperties='DMSSonarDocId,<...> '

. Я аутентифицируюсь, используя токен на предъявителя, сгенерированный для моего пользователя.Этот запрос возвращает 7 элементов.Затем я выполняю тот же URL в своем браузере с моим пользователем (NTLM), и он возвращает 10 элементов.Это еще не все.Я генерирую токен для моего пользователя еще раз.Вставьте его в предыдущий запрос GET с токеном на предъявителя, и он вернет 10 элементов ... Я жду несколько секунд, скажем, 30 ... ПОЛУЧИТЕ еще раз, и мне вернули 7 элементов (всегда одинаковые)!И это 100% тиражируется.После очередного GET из браузера и регенерации токена 10 предметов, через некоторое время на том же токене 7 предметов ....

Обновление.Я обнаружил разницу в журналах в ULS: при правильной работе: 

Context has no SMTP/UPN claims. IdentityContext: '{"nameid":"s-1-5-21-2843295230-2675739751-2774624307-1482","nii":"urn:office:idp:activedirectory","upn":"kowalj@spdev.loc","userId":"0#.w|spdev\\kowalj","appliesTo":"https:\/\/sonar-sandbox.spdev.loc\/"}'

при неправильной работе: 

Context has no SMTP/UPN claims. IdentityContext: '{"nameid":"s-1-5-21-2843295230-2675739751-2774624307-1482","nii":"urn:office:idp:activedirectory","upn":"spdev\\kowalj","userId":"0#.w|spdev\\kowalj","appliesTo":"https:\/\/sonar-sandbox.spdev.loc\/"}'

ДРУГИЕ НАХОДКИ: Отсутствуют элементы, которые назначены мне напрямую -не через группу, разрешенную нашим провайдером нестандартных заявок - да, у нас есть провайдер нестандартных претензий, который долгое время работал нормально (мы использовали только авторизацию NTLM).Мы отправляем эти претензии: 

new Claim[]
{
    new Claim("nameid", sid),
    new Claim("nii", Constants.Auth.Token.IdentityIssuer)
};

ДРУГИЕ НАХОДКИ: Когда все работает правильно, выполнение этого кода в решении фермы SP в некотором прокси REST: ((ClaimsIdentity)HttpContext.Current.User?.Identity).Claims.FirstOrDefault(c => c.ClaimType.EqualsIgnoreCase(ClaimTypes.Upn)) возвращает upn.Когда поиск не работает, тот же код возвращает ноль ... И, как я уже сказал, я могу обновить страницу, и в начале есть upn, а через некоторое время его нет ...

1 Ответ

1 голос
/ 14 мая 2019

Я нашел работу вокруг.Не очень хорошо, но пока я не вижу другого варианта.Мы запустили претензии к службе токенов Windows и, если пользователь делает какие-то запросы к нашему приложению, мы время от времени обращаемся к нашему настраиваемому прокси-серверу, помещенному в решение фермы SharePoint, для имитации использования SharePoint этим пользователем с помощью обычной проверки подлинности Windows:

public void RefreshUpn()
{
    WindowsImpersonationContext _wic = null;
    try
    {
        string login = HttpContext.Current.User.Identity.Name;
        login = login.Substring(login.LastIndexOf('|') + 1);
        string[] loginParts = login.Split('\\');
        string loginForUpnLogon = Culture.Invariant($"{loginParts[1]}@{loginParts[0]}");
        WindowsIdentity wi = S4UClient.UpnLogon(loginForUpnLogon);

        if(wi == null)
        {
            throw new InvalidOperationException(Culture.Invariant($"Could not impersonate user '{HttpContext.Current.User.Identity.Name}'."));
        }

        _wic = wi.Impersonate();

        using (var wc = new WebClient())
        {
            wc.UseDefaultCredentials = true;
            var requestUrl = HttpContext.Current.Request.Url;
            wc.DownloadString(requestUrl.Scheme + "://" + requestUrl.Host + "/_api/web/currentuser");
        }
    }
    finally
    {
        _wic?.Undo();
    }
}

После такого запроса SharePoint правильно отвечает нам в течение 150 секунд.

...