TFS rest api, разрешающий GET, но не PATCH

Question

Я пытаюсь изменить статус для рабочего элемента, используя API остальных, предоставленный моим обновлением 3 TFS 2015 (локально).Когда я пытаюсь получить список своих товаров, все работает нормально:

var client = new RestClient(uri);
client.Authenticator = new HttpBasicAuthenticator(this.TFSUsername, this.SecurityToken);
var request = new RestRequest(Method.GET);
request.AddHeader("cache-control", "no-cache");

IRestResponse response = client.Execute(request);

После того, как я получу этот ответ и у меня будет вся необходимая информация, я собирался обновить статус одной из этих работ.items.

Используя тот же подход (и, конечно, те же учетные данные), я получаю код состояния 401 , как я пытался сделать это анонимно .

Единственное отличие состоит в том, что я использую глагол PATCH (как сказано в документации), и что я передаю тело, чтобы определить, какой статус я хочу редактировать.

Это код, который яИспользую для редактирования:

var client = new RestClient(uri);
client.Authenticator = new HttpBasicAuthenticator(this.TFSUsername, this.SecurityToken);
var request = new RestRequest(Method.PATCH);
request.AddHeader("cache-control", "no-cache");

string body = @"
  {
   'op':'add',
   'path':'/fields/System.State',
   'value':'Closed'
  }";
request.AddJsonBody(body);
IRestResponse response = client.Execute(request);

Есть ли какие-либо подсказки о том, почему просто изменение HTTP VERB вызывает у меня эту проблему с авторизацией?

Попытка сделать это с помощью Postman вызывает у меня ту же проблему.

ОБНОВЛЕНИЕ:

глядя на заголовок ответа, я заметил это:

X-TFS-ProcessId →e2b98235-1d3a-4bb7-868f-0d91805aa307
ActivityId →08909688-ac81-4c37-9cea-b47e84fd3efe
X-TFS-Session →08909688-ac81-4c37-9cea-b47e84fd3efe
X-VSS-E2EID →08909688-ac81-4c37-9cea-b47e84fd3efe
X-FRAME-OPTIONS →SAMEORIGIN
WWW-Authenticate →Basic realm="http://xxxxxxx/tfs"
WWW-Authenticate →Negotiate
WWW-Authenticate →NTLM
X-Powered-By →ASP.NET
P3P →CP="CAO DSP COR ADMa DEV CONo TELo CUR PSA PSD TAI IVDo OUR SAMi BUS DEM NAV STA UNI COM INT PHY ONL FIN PUR LOC CNT"
Lfs-Authenticate →NTLM
X-Content-Type-Options →nosniff
Date →Thu, 28 Feb 2019 00:20:57 GMT
Content-Length →0

Что привлекло мое внимание было:

WWW-Аутентификация → Основная область = "http://xxxxxxx/tfs"

WWW-Аутентификация → Переговоры

WWW-Authenticate → NTLM

Таким образом, он будет поддерживать базовую аутентификацию как получение, но не работает."Переговоры" и "NTLM" как-то мешают?

Спасибо

Answer 1

После долгих попыток я обнаружил, что решение довольно простое.

Чтобы оно работало с точки зрения аутентификации, достаточно использовать NtlmAuthenticator (сИмя пользователя и пароль) вместо HttpBasicAuthenticator (хотя работает для получения).Я заменил свой аутентификатор на NtlmAuthenticator как для получения, так и для исправления, и теперь он работает нормально.

var client = new RestClient(uri);
client.Authenticator = new NtlmAuthenticator(this.TFSUsername, this.TFSPassword);

Другая сложная часть, которую я обнаружил (не точно связана с аутентификацией), это то, что для PATCH тип содержимогодолжно быть application / json-patch + json

Надеюсь, это поможет