Расширение API в одном проекте полностью раскрывает ссылочный API, но маршрутизирует конфликт - PullRequest
Новая
       27

Расширение API в одном проекте полностью раскрывает ссылочный API, но маршрутизирует конфликт

0 голосов
/ 18 сентября 2018

Я пытаюсь разделить проект Core 2.1 WebAPI на два, чтобы мы могли предоставить два разных API в зависимости от обстоятельств.Упрощенно, у нас есть один API, и мы хотим, чтобы все запросы только для чтения (GET) были в одном API, а весь набор - в другом (API «admin»).Swagger включен в проектах.

Я продублировал проект, переименовал один (пространства имен и т. Д.) И добавил оба к одному решению, затем закомментировал все методы контроллера не-GET в проекте только для чтения.и закомментировал все методы GET в проекте администратора.Затем я добавил ссылку на проект, предназначенный только для чтения, в проекте администратора.

При запуске проекта, доступного только для чтения, страница swagger подошла нормально, только GET.Запущенный админский проект дал 500 на развязной странице.Интересно, что во время отладки я обнаружил, что удаление всех контроллеров из проекта администратора, базового API из проекта только для чтения, было полностью открыто и казалось полностью функциональным - не то, что я ожидал, а потенциальная проблема безопасности для любого, кто не ожидаетit.

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

Базовый класс: 

namespace InfoFeed.WebAPI.Features.Account
{
    /// <summary>
    /// Handle user account related tasks
    /// </summary>
    [Authorize]
    [Produces("application/json")]
    [Route("api/account")]
    public class AccountController : Controller
    {
        private readonly ILogger _log;
        protected readonly IMediator _mediator;

        public AccountController(ILogger<AccountController> log,
                                 IMediator mediator)
        {
            _log = log;
            _mediator = mediator;
        }

Класс потомка: 

namespace InfoFeedAdmin.WebAPI.Features.Account
{
    /// <summary>
    /// Handle user account related tasks
    /// </summary>
    [Authorize]
    [Produces("application/json")]
    [Route("api/account")]
    public class AccountAdminController 
        : InfoFeed.WebAPI.Features.Account.AccountController
    {
        public AccountAdminController(ILogger<AccountAdminController> log,
                                 IMediator mediator)
            : base(log, mediator)
        {
        }

Я подумал, что, возможно, маршрут может вызывать конфликт, поэтому я попытался изменить его на [Route ("api / admin/ account ")] - это работало, пока не было сигнатур метода столкновения.Тем не менее, это означает, что есть два набора маршрутов, доступных для одного и того же метода контроллера. 

POST /api/account/signin
GET /api/account/signout

POST /api/admin/account/signin
GET /api/admin/account/signout

Кто-нибудь знает, как я могу скрыть (возможно, выборочно) маршруты от класса предков, чтобы только маршрутыЯ выбираю выставить из потомка класса видны / доступны?

Приветствия

1 Ответ

0 голосов
/ 18 сентября 2018

По умолчанию MVC будет искать дерево зависимостей и находить контроллеры (даже в других сборках).
Вы можете использовать application parts, чтобы избежать поиска контроллеров в конкретной сборке или местоположении.

Если у вас есть сборка, содержащая контроллеры, которые вы не хотите использовать, удалите ее из ApplicationPartManager: 

services.AddMvc()
.ConfigureApplicationPartManager(apm =>
{
    var dependentLibrary = apm.ApplicationParts
        .FirstOrDefault(part => part.Name == "DependentLibrary");

    if (dependentLibrary != null)
    {
       p.ApplicationParts.Remove(dependentLibrary);
    }
})

Источник: https://docs.microsoft.com/en-us/aspnet/core/mvc/advanced/app-parts?view=aspnetcore-2.1

...