Почему мои настраиваемые маршруты конфликтуют с атрибутом AccountController / [Authorize]? - PullRequest
0 голосов
/ 14 июля 2020

Я использую. Net Core 3.1, Razor Project с отдельным набором «автономных» контроллеров. Я также использую OID C для авторизации. Мне удалось заставить OID C работать с поставщиком OAuth2 нашей компании. Во время этой реализации я заметил, что мои пользовательские маршруты, похоже, вызывают серьезные проблемы с ASP. NET Core's Identity Convention. Я приведу пример оболочки моего Контроллера учетной записи, чтобы остальная часть текста имела больше смысла:

[Route("api/account")]
    [ApiController]
    public class AccountController : Controller
    {
        [AllowAnonymous]
        [HttpGet]
        [Route("login")]
        public async Task Login(string returnUrl = "/")
        {
            if (!HttpContext.User.Identity.IsAuthenticated)
            {
                await HttpContext.ChallengeAsync("OpenIdConnect", new AuthenticationProperties() { RedirectUri = returnUrl });
            }

            else
            {
                await SetCustomerGuidCookie();
            }
        }

        [AllowAnonymous]
        [HttpPost]
        [Route("logout")]
        public async Task Logout()
        {
            await HttpContext.SignOutAsync("OpenIdConnect",
                new AuthenticationProperties() {RedirectUri = "/"});

            await HttpContext.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
        }
    }

Например, когда я пытался настроить действие контроллера для обратного вызова, мой OID C предоставляет с настраиваемой маршрутизацией ("api / account / callback") это НИКОГДА не попадет в оформленное действие в AccountController выше. (Да, точка останова не сработала!) (Представьте себе действие обратного вызова с атрибутом Route («обратный вызов»). Однако, как только мы поместим метод обратного вызова в другой контроллер, это не будет AccountController, например мой UserController, Проблем не было вообще. Сработала точка останова, действие выполняло обратный вызов.

Это всего лишь небольшая предварительная информация, чтобы дать вам некоторый контекст, в каком общем направлении, по моему мнению, проблема.

Теперь, если я попытаюсь защитить Razor Pages с помощью атрибута [Authorize] в модели ... (:)

[Authorize]
    public class RegistrationModel : PageModel
    {
        // some model stuff :)
    }

... насколько я понимаю, это должно просто вызвать AccountController / Действие входа. И при запуске приложения оно фактически выполняет go действию и каким-то образом генерирует правильный ReturnUrl !,

localhost:5001/Account/Login?ReturnUrl=%2FRegistration

, но на странице просто отображается 404, а точка останова в моем действии AccountController / Login - не попал. Какой. файл. ебать.

Я попытался найти конфигурации или информацию об атрибуте [Authorize] и, возможно, настроить маршрут входа (на мой собственный маршрут «api / account / login»), но, похоже, это глубоко вложен в «Соглашение по конфигурации» ASP. NET Черный ящик Core 3.1.

Однако зашнурованный элемент html в представлениях Razor, например:

<a asp-controller="Account" asp-action="Login">Log in</a>

или это

<form asp-controller="Account" asp-action="Logout" method="post" id="logout_form"></form>

безупречно go в AccountController, попадание в точки останова на действиях и правильное выполнение их материала OAuth.

Я немного не понимаю, что здесь происходит не так. Если потребуется больше кода, я отправлю фрагменты по запросу.

1 Ответ

0 голосов
/ 24 июля 2020

Мы исправили это, изменив настраиваемую маршрутизацию AccountController с [Route("api/account")] на [Route("account")].

После нескольких часов исследований ничего не помогло.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...