Предоставление доступа роли READER к подписке в Azure отлично работает в Postman, но не через Angular. Почему?

Хорошо, мне может не хватать чего-то простого здесь, в Angular, но мне действительно нужна помощь. Я пытаюсь программно предоставить подписке роль READER участника-службы. Если я использую PostMan, он работает нормально. Однако, когда я отправляю тот же запрос PUT через Angular6, я получаю от Azure ошибку 400, в которой говорится:

Содержание вашего запроса недействительно, и исходный объект не может быть десериализован. Сообщение об исключении: «Разрешения на обязательное свойство» не найдены в JSON. Путь 'properties', строка 1, позиция 231. '

В обоих случаях отправляется JSON:

{
    "properties": 
    { 
        "roleDefinitionId":"/subscriptions/{some_subscription_guid}/providers/Microsoft.Authorization/roleDefinitions/acdd72a7-3385-48ef-bd42-f606fba81ae7",
        "principalId":"{some_service_provider_guid}" 
    }
}

Я захватил трафик из обоих запросов, и они отображаются как полезные данные приложения / json в PUT. Итак, я не понимаю, что неправильно десериализуется через Azure, что вызывает эту ошибку. Я пытаюсь следовать инструкциям REST, описанным здесь: https://docs.microsoft.com/en-us/azure/role-based-access-control/role-assignments-rest

Любые идеи, что мне не хватает?

ОБНОВЛЕНИЕ

Добавление RAW REQUEST для каждого запроса. Я заменил все конфиденциальные данные (токен доступа, идентификаторы GUID и т. Д.), Ничего не изменив в выводе Fiddler.

PUT https://management.azure.com/subscriptions/<VALID_SUBSCRIPTION_WAS_HERE>/providers/Microsoft.Authorization/roleDefinitions/7ec2aca1-e4f2-4152-aee2-68991e8b48ad?api-version=2015-07-01 HTTP/1.1
Host: management.azure.com
Connection: keep-alive
Content-Length: 233
Accept: application/json, text/plain, */*
Origin: http://localhost:4200
Authorization: Bearer <VALID_TOKEN_WAS_HERE>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Content-Type: application/json
Referer: http://localhost:4200/token/<VALID_DOMAIN_WAS_HERE>.onmicrosoft.com/graph
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9

{"properties": { "roleDefinitionId":"/subscriptions/<VALID_SUBSCRIPTION_GUID_HERE>/providers/Microsoft.Authorization/roleDefinitions/acdd72a7-3385-48ef-bd42-f606fba81ae7", "principalId":"<VALID_OBJECTID_HERE>" }}

person Dana Epp    schedule 15.07.2018    source источник
comment
Почтальон выполняет неявное кодирование / преобразование символов в зависимости от указанной вами полезной нагрузки и типа содержимого. Тот факт, что он работает в Postman, означает, что ваша полезная нагрузка angular должна немного отличаться. Захватите оба запроса с помощью прокси-сервера Fiddler или Postman и используйте инструмент сравнения для обоих, включая заголовки.   -  person Josh    schedule 16.07.2018
comment
Да, я использовал Fiddler для проверки тела, и оба они показывают одну и ту же полезную нагрузку JSON. Между браузером и настольным приложением Postman действительно разные заголовки, но это не имеет значения. Также есть заголовок тега почтальона, но Azure следует игнорировать это.   -  person Dana Epp    schedule 16.07.2018
comment
разместите весь свой request от angular. Воспользуйтесь вкладкой Raw в инспекторе Fiddler. Вы можете убрать / скрыть заголовок авторизации.   -  person astaykov    schedule 16.07.2018
comment
ОК @astaykov, я обновил исходный вопрос с помощью дампа запроса RAW Fiddler. Что-нибудь выглядит неуместным?   -  person Dana Epp    schedule 16.07.2018


Ответы (1)


Хорошо, я наконец понял, что здесь происходит. Похоже, что я отправлял сообщение не на ту конечную точку. Мне нужно отправлять сообщения в roleAssignment, а не в roleDefinitions.

Так почему это сработало в PostMan? Похоже, есть откат от предыдущей версии API, которая поддерживала оба при использовании устаревших клиентов, которые по какой-то причине PostMan не выдержали. Однако при публикации через Angular он активно его отклонял.

Конечный результат ... отправьте в «/Microsoft.Authorization/roleassignments/» с версией API более поздней, чем «api-version = 2015-07-01». Все будет работать.

person Dana Epp    schedule 17.07.2018