none
WPFアプリケーションでのThread.CurrentPrincipalの設定 RRS feed

  • 質問

  • ログインという処理のあるWPFアプリケーションで、ユーザがログインしていることを示すのにThread.CurrentPrincipalを使用する場合、Thread.CurrentPrincipalはどこで(いつ)設定するのが一般的でしょうか?

     

    例えば、WPFアプリケーションを普通に作成した場合は、Application(を継承したApp)のStartupイベントなどが、アプリケーションの初期化タイミングになると思いますが、ここでThread.CurrentPrincipalを設定してもイベント終了後に元に戻ってしまいます。

     

    調べてみた感じでは、Startupイベント自体もディスパッチャで非同期に実行されるため、StartupイベントではSecurityContextがフローされた状態になっており、イベント終了時にSecurityContextが元に戻されて、Thread.CurrentPrincipalも元に戻る、ということのように思われます。

     

    回避方法としては、Mainを自作して、ディスパッチャなどを介さないメインの流れで直にThread.CurrentPrincipalをセットするか、StartupイベントでSecurityContext.SuppressFlowした上でディスパッチャのBeginInvokeでThread.CurrentPrincipalをセットする処理をキューに登録しておく(Startupイベント終了後に、SecurityContextをフローさせないでThread.CurrentPrincipalを設定する)、辺りが考えられます。

     

    いずれも試した限りではうまく動作したのですが、どうにも強引というか行き当たりばったりな感が否めません。

     

    普通はこうするだろう、こうするのが正しいというような、あるいは正当な方法が用意されているならそれを使いたいのですが、どうにも見つからない状態です。

    どなたかこの辺り情報をお持ちでないでしょうか?

     

    --追記

    ちょっと訂正、SecurityContext.SuppressFlowでは駄目で、ExecutionContext.SuppressFlowにする必要がありました。

    最初にExecutionContextでうまくいったので、次にSecurityContextで試してこちらもうまくいったと思っていたのですが、確認方法のミスで実はうまくいってませんでした(ExecutionContextだとうまくいきます)。

    2008年7月15日 15:14

すべての返信

  • もちょっと調べてみたところ、英語のフォーラムにありました…

    http://forums.msdn.microsoft.com/en-US/wpf/thread/67bada95-2d3d-40fd-94e3-b910c1d823ef/

     

    ここを見ると、AppDomain.SetThreadPrincipal メソッドでデフォルトのPrincipalを設定してしまえということのようですね。

    これも思いついてはいたんですが、デフォルトのPrincipalを認証済み(ログイン済み)に設定してしまうのにはどうも違和感があったので回避策候補からははずしていました。

     

    しかしよく考えれば、MainのスレッドのThread.CurrentPrincipalを設定するのも、実質的にはあまり変わらないですね。

    後で認証済みではない状態に差し替えようとしても、単純にやったら同じことになる(予想に反して認証済みの状態に戻ってしまう)ので、デフォルトのPrincipalを設定してしまうのと事実上大差はない感じです。

     

    うーんしかしいまいちしっくりこない。

    2008年7月15日 15:48