Я пытаюсь использовать IHttpContextAccessor в моем веб-интерфейсе .net core 2.0, и когда я обращаюсь к контексту, это всегда WindowsPrincipal, хотя я четко вижу, что моя конфигурация аутентификации работает (jwt bearer) нормально и в TokenValidated, HttpContext там есть мой ClaimsPrincipal и мои претензии. Почему IHttpContextAccessor не использует правильный HttpContext. Он зарегистрирован в службах через DI, как и положено. У кого-нибудь есть идеи? Это использует приемник httpsys в Service Fabric.
Вот дополнительная информация:
Эта строка является последней строкой для настройки IServiceCollection 'services'
services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
Это ПОСЛЕ аутентификации (AddJwtBearer), политик авторизации, защиты данных, CORS и т. Д.
Я использую Serilog с пользовательскими Enrichers, которые обогащают данные, записанные в журналы, информацией HttpContext. Эти обогащающие устройства инициализируются ссылкой IHttpContextAccessor, поэтому они могут вызывать HttpContext, чтобы получить от него определенную информацию для ведения журнала. Когда журналы записываются, когда нет http-контекста, он игнорирует это, но когда журналы записываются внутри действия контроллера, он должен иметь возможность получать данные из контекста. Если я устанавливаю точку останова и сравниваю HttpContext непосредственно в контроллере с тем, что находится в HttpContext, который имеет IHttpContextAccessor, они отличаются. Обычный, доступный непосредственно в контроллере, показывает мой ClaimPrincipal с утверждениями, но IHttpContextAccessor один показывает WindowsPrincipal без утверждений, но у него есть URL-адрес, строка запроса и т. Д.
Я полагал, что порядок может повлиять на него, и поэтому я поставил его ПОСЛЕ настройки других элементов.
Используется HttpSysCommunicationListener в службе Service Fabric.