Выпуск списков чтения из Sharepoint listdata.svc из другого сервиса REST

Question

все.

Я создал REST ApiController, который, среди прочего, пытается вызвать /_vti_bin/listdata.svc сайта Sharepoint, чтобы получить содержимое одного или нескольких списков Sharepoint.

Web.config ApiController использует аутентификацию Windows без олицетворения. В коде я использую System.Net.CredentialCache.DefaultNetworkCredentials для DataContext.Credentials.

Когда я запускаю службу локально с помощью Visual Studio, ApiController может вызвать listdata.svc без каких-либо проблем и может получить полное содержимое списка (ов).

Однако, когда я развертываю ApiController на реальном сервере IIS, который выполняется под системной учетной записью, вызов listdata.svc не получает никаких результатов. Из того, что я вижу в моем протоколе ApiController, нет никаких исключений. Согласно журналам, список (ы) просто выглядит пустым (0 элементов).

Я проверил, чтобы системная учетная запись IIS имела надлежащий доступ к сайту Sharepoint.

Любые идеи о том, почему разница в поведении?

Answer 1

Выяснил проблему. И проблема смущает, учитывая тот факт, что я был администратором сайта SharePoint за один раз.

Я забыл, что с SharePoint можно иметь как сайт , так и список разрешений для данного сайта, которые не наследуются друг от друга.

По какой-либо причине на этом сайте был установлен набор разрешений для списка, к которому я пытался получить доступ, который отличался от сайта в целом.

У системных учетных записей использовались разрешения на полный доступ. Но для рассматриваемого списка у них не было прав (но другие учетные записи, например, мои собственные). Это объясняет, почему системные учетные записи могут подключаться к службе списка сайтов, но список выглядит пустым.

После предоставления системным учетным записям прав доступа к списку все работает.

Lession here: Просто потому, что учетная запись имеет разрешения на работу, не означает, что она применяется ко всем спискам на сайте, если администратор решает разрешить списки отдельно.

Надеюсь, все вышеизложенное имеет смысл.