Как реализовать управление версиями для конечной точки токена в Web API 2 - PullRequest
Новая
       95

Как реализовать управление версиями для конечной точки токена в Web API 2

0 голосов
/ 12 февраля 2020

У меня есть Asp. Net Web API 2 с использованием аутентификации на основе токенов (OAuth2).

Я реализовал управление версиями Web API с использованием как pnet -api-versioning .

Итак, теперь у меня есть три разные версии моего API. Это действительно здорово, теперь я могу изменить V3, не влияя на текущий API.

Но конечная точка /token не является версионной, потому что ее нет в моем контроллере. Это в Провайдерах.

Я искал, но не мог найти ничего полезного.

Ответы [ 2 ]

0 голосов
/ 25 февраля 2020

Я не знаком с этой конкретной настройкой, но это похоже на промежуточное ПО. Здесь недостаточно информации, чтобы предоставить вам конкретный c ответ, но ваши цели должны быть достижимы одним из нескольких способов:

Вариант 1. Использование API соглашений

Если ваша конечная точка авторизации на самом деле является контроллером (хотя я думаю, что это не так), вы можете использовать Соглашения API примерно так: 

services.AddApiVersioning(options =>
{
    options.Conventions.Controller<OAuthController>().IsApiVersionNeutral();
}

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

Вариант 2. Использование пользовательского соглашения

Промежуточное программное обеспечение может создавать действия динамически. Пока действия действительно выполняются, вы можете использовать пользовательскую IControllerConvention . Вам будет передан ControllerModel , который содержит действия, необходимые для версии. Предполагая, что это правильное поведение, вы будете искать соответствующие действия в исходной модели, а затем сможете применить его к соглашениям контроллера с помощью чего-то вроде: 

public class MyConventions : IControllerConvention
{
  public bool Apply(IControllerConventionBuilder controller, ControllerModel controllerModel)
  {
    var method = // TODO: resolve the target method from controllerModel

    if (method == null)
    {
      return false;
    }

    controller.Action(method).IsApiVersionNeutral();
    return false;
  }
}

Опция 3 - в промежуточном ПО

Если это чисто промежуточное ПО, управление версиями API там напрямую не поддерживается. Однако вы можете самостоятельно поддерживать управление версиями, если конвейер составлен правильно. В частности, управление версиями API должно предшествовать другим частям промежуточного программного обеспечения, которым это необходимо. Обычно это происходит автоматически, но если вам нужно контролировать регистрацию, вам нужно изменить настройки, чтобы обрабатывать ее вручную следующим образом: 

services.AddApiVersioning(options => options.RegisterMiddleware = false);

// ... inside application setup
services.UseApiVersioning();

Промежуточное ПО API управления версиями на самом деле не делает ничего особенного. Это просто добавляет функцию конвейера. Пока это еще до вашего другого промежуточного программного обеспечения, оно будет доступно в нисходящем направлении, как это: 

var feature = context.Features.Get<IApiVersioningFeature>();

// the raw, unparsed API version, if any
var rawApiVersion = feature.RawApiVersion;

// the parse API version; will be null if no version is specified
// or the value cannot be parsed
var apiVersion = feature.ApiVersion;

// TODO: enforce versioning policies within the middleware

Вариант 4. Используйте API Explorer

Если ни один из предыдущих подходов не будет работать для вас, Вы можете использовать расширения API Explorer для управления версиями API, чтобы построить свою конфигурацию (как описано выше) из обнаруженных API. Преимущество этого состоит в том, что вы не будете жестко закодированы или не будете требовать изменений каждый раз, когда вы выпускаете новую версию.

Конфигурация запуска вашего приложения изменится на что-то вроде этого: 

public void Configure(IApplicationBuilder app, IApiVersionDescriptionProvider provider)
{
  foreach (var description in provider.ApiVersionDescriptions)
  {
    var options = new OAuthAuthorizationServerOptions()
    {
      TokenEndpointPath = new PathString($"/api/{description.GroupName}/Accounts/Token"),
      Provider = new ApplicationOAuthProvider2(PublicClientId),
      AccessTokenExpireTimeSpan = TimeSpan.FromDays(TokenExpirationInDays),
      AllowInsecureHttp = true,
    };

    app.UseOAuthBearerTokens(options);
  }
}
0 голосов
/ 17 февраля 2020

Мы можем зарегистрировать более одной конечной точки токена в Startup.Auth.cs

Итак, вот что я сделал: 

        OAuthOptions = new OAuthAuthorizationServerOptions
        {
            TokenEndpointPath = new PathString("/Token"),
            Provider = new ApplicationOAuthProvider(PublicClientId),
            AuthorizeEndpointPath = new PathString("/Account/ExternalLogin"),
            AccessTokenExpireTimeSpan = TimeSpan.FromDays(TokenExpirationInDays),
            AllowInsecureHttp = true, //Allow HTTP to send username password.
        };
        app.UseOAuthBearerTokens(OAuthOptions);

        OAuthOptionsV3 = new OAuthAuthorizationServerOptions
        {
            TokenEndpointPath = new PathString("/api/V3/Accounts/Token"),
            Provider = new ApplicationOAuthProvider2(PublicClientId),
            AccessTokenExpireTimeSpan = TimeSpan.FromDays(TokenExpirationInDays),
            AllowInsecureHttp = true, //Allow HTTP to send username password.
        };
        // Enable the application to use bearer tokens to authenticate users
        app.UseOAuthBearerTokens(OAuthOptionsV3);

Так что теперь у меня есть разные конечные точки токена для каждой версии.

...