Я не знаком с этой конкретной настройкой, но это похоже на промежуточное ПО. Здесь недостаточно информации, чтобы предоставить вам конкретный 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);
}
}