System.InvalidOperationException: Нет обработчика аутентификации не настроен для обработки схемы: Автоматический

Question

Сценарий:

1. Создание нового Asp.Net основного проекта (версия 1.0.0)
2. Выберите шаблон Web API
3. Добавьте атрибут [Authorize] по умолчанию ValuesController
4. запустить приложение

Если я г ип приложение с IIS и сделать запрос GET в http://localhost:60513/api/values я получить ожидаемый 401 Unauthorized error

Если же я запустить приложение с Kestrel (например: dotnet run) и сделать запрос GET к http://localhost:5000/api/values я получаю 500 Internal Server Error за исключением следующего в пустельга:

Now listening on: http://localhost:5000 
Application started. Press Ctrl+C to shut down. 
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1] 
     Request starting HTTP/1.1 GET http://localhost:5000/api/values 
info: Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2] 
     Authorization failed for user: . 
warn: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[1] 
     Authorization failed for the request at filter 'Microsoft.AspNetCore.Mvc.Authorization.AuthorizeFilter'. 
info: Microsoft.AspNetCore.Mvc.ChallengeResult[1] 
     Executing ChallengeResult with authentication schemes(). 
fail: Microsoft.AspNetCore.Server.Kestrel[13] 
     Connection id "0HKUMMBBBQ6AU": An unhandled exception was thrown by the application. 
System.InvalidOperationException: No authentication handler is configured to handle the scheme: Automatic 
    at Microsoft.AspNetCore.Http.Authentication.Internal.DefaultAuthenticationManager.<ChallengeAsync>d__12.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at Microsoft.AspNetCore.Mvc.ChallengeResult.<ExecuteResultAsync>d__14.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.<InvokeResultAsync>d__32.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.<InvokeAsync>d__18.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at Microsoft.AspNetCore.Builder.RouterMiddleware.<Invoke>d__4.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at Microsoft.AspNetCore.Hosting.Internal.RequestServicesContainerMiddleware.<Invoke>d__3.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Frame`1.<RequestProcessingAsync>d__2.MoveNext() 
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2] 
     Request finished in 282.8427ms 200 

Мой вопрос Почему мое приложение отличается результат в зависимости от сервера, на котором это? Почему Kestrel и IIS обрабатывают авторизацию по-другому?

Обратите внимание, что в StackOverflow есть похожие вопросы, такие как this или this other, но все они предназначены для более сложных сценариев, в которых задействованы фильтры или промежуточное программное обеспечение.

У меня нет промежуточного программного обеспечения в конвейере AspNet, отличном от MVC, и весь код, но атрибут [Authorize] автоматически генерируется шаблоном AspNet Web Api.

Answer 1

В соответствии с this thread в системе безопасности AspNet атрибут Authorize для любого действия или контроллера требует, по крайней мере, одного промежуточного промежуточного ПО в конвейере для решения проблем. При использовании IIS используется промежуточное программное обеспечение IIS, но при использовании Kestrel нет промежуточного ПО auth, связанного с этим, поэтому нам нужно добавить наше собственное.