REST-вызов Azure API Management для создания подписки для пользователя (отсутствует) - PullRequest
0 голосов
/ 06 января 2019

Я пытаюсь делегировать подписку на продукт из Azure API Management, используя приведенный пример здесь . Мой прототип имеет действующее делегирование аутентификации пользователя, однако делегирование подписки на продукт вызывает недоумение.

Во время делегирования имени пользователя я получаю запрос от APIM на мою страницу делегирования и обрабатываю его в соответствии с примером ссылки выше без проблем. Во время делегирования подписки на продукт сначала выполняется звонок на мою страницу входа в систему; не страница делегирования. Это приводит меня к моей первой серии вопросов:

  1. Может ли кто-нибудь объяснить, почему делегирование подписки на продукт в корне отличается от делегирования аутентификации пользователей?
  2. Если страница делегирования входа (согласно приведенному выше примеру) обрабатывает аутентификацию пользователя, установив User.Identity.IsAuthenticated, почему делегирование продукта не может сделать то же самое и почему оно будет отправлено на страницу входа, а не на страницу делегирования?

Я справился с вышеуказанной проблемой, используя страницу входа в систему, чтобы оценить, прошла ли аутентификация пользователя сначала, а затем перенаправить их на returnUrl следующим образом:

if (User.Identity.IsAuthenticated)
{
    return LocalRedirect(returnUrl);
}

Значение returnUrl, предоставленное APIM, содержит следующие переменные:

  • Путь = /Identity/Account/Manage/Delegate
  • productId = [productId]
  • userId = [userId]
  • операция = Subscribe
  • соль = [salt]
  • sig = [sig]

Поскольку это ВСЕ переменные, указанные в returnUrl от APIM, у меня есть следующие вопросы:

  1. Следуя документации о подписке с использованием APIM REST API , как определить следующие обязательные свойства:

    • subscriptionId
    • resourceGroupName
    • serviceName
    • sid
  2. Дополнительно для тела запроса, как вы определяете properties.scope согласно этой ссылке .

В качестве теста я установил точку останова в коде непосредственно перед вызовом метода PUT в конечной точке, содержащей следующую строку кода. Я использовал Postman для тестирования создания подписки, скопировав заголовок Authorization в VS2017 и все соответствующие данные заголовка / тела. Мне удалось получить ответ 201, указывающий, что подписка была создана, однако она нигде не отображается на портале APIM, и у меня, конечно, не было многих «обязательных» свойств, как определено в статье документации:

response = await client.PutAsync("/subscriptions/" + subscriptionId + "?api-version=" + apiVersion, new StringContent(ApimSubscriptionJson, Encoding.UTF8, "text/json"));

APIM PUT RESPONSE

Вот тело моего тестового вызова API:

{
    "userId" : "/users/c22afea6-3e9c-4b85-87a6-2d5e97e259cf",
    "scope" : "/products/ring-0-beta-access"
}

Исходя из этой странности, у меня есть следующие дополнительные вопросы:

  1. Если подписка на продукт действительно создана, где она будет, если не на портале Azure APIM? Он также не отображается в профиле пользователя.
  2. Как я могу получить ответ 201 на метод PUT, если я не предоставил API-интерфейсу REST APIM все необходимые параметры?

1 Ответ

0 голосов
/ 07 января 2019

Я нашел решение и хотел поделиться.

Я был в порядке, чтобы использовать метод, описанный в канале 9 видео. Я просто использовал неправильное свойство. Вместо userId должно быть ownerId. После запуска GET в моих подписках я заметил, что вижу их всех. Они не связаны с пользователем, поэтому они не отображаются на портале Azure APIM.

Еще одним ключевым промахом были уведомления. Если вы пропустите параметр строки запроса &notify=true, вы не будете получать уведомления, когда кто-то подписывается на ваш API. Это особенно хлопотно, когда ваш API требует одобрения.

Это похоже на потенциальную ошибку продукта, так как вы не сможете создать подписку «без владельца». Это почти невозможно найти, если вы не знаете, где искать.

...