Odataを混在させるとカスタムSystem.Web.Http.AuthorizeAttributeが壊れる

Question

Web Apiアプリケーションは長い間働いています。

当社は、ユーザーの状態と役割プロバイダを初期化するために、私たち自身のSystem.Web.Http.AuthorizeAttributeを実装し、のisAuthorized（当社の過負荷時のき）我々はすべて私たちのものを使用して初期化GenericPrincipal私たち自身にHttpContext.Current.UserとThread.CurrentPrincipalを設定します。

これは長い間うまくいきました。

私たちはgitからv6.15を取得したので、いくつかのOdata APIを立ち上げるように依頼されました。これは、他のdll（新しい/別のmvc dllなど）に沿ってドラッグされました。どのようにSystem.Web.Http.AuthorizeAttributeアクションがパイプラインに収まるか。

ここで、[Authorize (Roles="OurFoo")]は正しく認証していますが、Thread.CurrentPrincipalは実際にメソッドに入る前に、別のものでリセット/スワップアウトされています。それは壊れています

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

私達のcallstackの下位のパーミッション。

誰かがこれに遭遇し、適切な回避策を考えましたか？

私は、System.Web.Http.AuthorizeAttributeの代わりにSystem.Web.Mvc.AuthorizeAttributeをベースとしてスタック記事を見つけましたが、署名が異なり、Thread.CurrentPrincipalリセットに関する問題が発生するかどうかは不明です。

Answer 1

誰かがより良い答えを持っているかどうかはわかりません（アプリ全体を「新しい方法」に書き直すように言っています）が、私は回避策を見つけました。

認証ロジックをIsAuthorized（）関数で壊して、それをMessageHandlerに入れ、パイプラインでThread.CurrentPrincipalの設定が十分に早く処理されることを期待していました。それはうまくいくように見えた。