Смешивание в Odata messes up custom System.Web.Http.AuthorizeAttribute

Question

У нас есть приложение Web Api, которое работает в течение длительного времени.

Мы реализовали наш собственный System.Web.Http.AuthorizeAttribute инициализировать наши состояния пользователя и роли провайдеров, и во время нашей перегрузки IsAuthorized() мы устанавливаем HttpContext.Current.User и Thread.CurrentPrincipal к нашей собственной GenericPrincipal инициализируются все наши вещи.

Это хорошо работает долгое время.

Теперь нас попросили встать на некоторые адаты Odata, поэтому мы вытащили v6.15 из git и перетащили по множеству других DLL (например, новые/разные mvc-dll), которые изменили поведение как System.Web.Http.AuthorizeAttribute действия подходят в трубопроводе.

Теперь, когда наш [Authorize (Roles="OurFoo")] правильно разрешает, Thread.CurrentPrincipal получает сброс/заменяется чем-то другим, прежде чем мы действительно попадаем в наш метод. Это ломается

[PrincipalPermission(SecurityAction.Demand, Role = "OurFoo")] 

разрешений ниже в нашем стоп-сигнале.

Кто-нибудь еще сталкивался с этим и придумал правильное обходное решение?

Я нашел Stack статьи об использовании System.Web.Mvc.AuthorizeAttribute в качестве основы вместо System.Web.Http.AuthorizeAttribute но подписи разные, и было неясно, если бы что-нибудь о Thread.CurrentPrincipal получать сброса проблемы.

Answer 1

Не уверен, что у кого-то есть лучший ответ (кроме того, что мне нужно переписать все приложение «новый способ»), но я нашел работу.

Я нарушил нашу логику аутентификации с нашей авторизации в нашей функции IsAuthorized() и поместил ее в MessageHandler, надеясь, что он будет обработан достаточно рано в конвейере, который установил Thread.CurrentPrincipal. Это работало.