6

ワークフローを正しく理解していないと思います。Apache Shiro と Stormpath を使用して Scala で Web サービスを作成しています。私のユーザー認証プロセスは次のようになります。

1) POST リクエストからユーザー データを取得し、Stormpath で確認して、問題がなければページにリダイレクトします。

pathPrefix("api") {
  path("login") {
    post {
      AuthToken.fromRequest { (token: AuthToken) =>
        stormpathAuth(token) { subj =>
          log.info("Subj {}", subj.getPrincipal.toString)
          redirect("/some/page", StatusCodes.Found)
        }
      }
    }
  }

ログで、Shiro は私に Stormpath アカウントを持つ正しいサブジェクトを返しました。次に、サブジェクトを抽出して、コードで使用します。

pathPrefix("some") {
  loggedInUser { subject =>
    path("page") {
      get {
        complete {
          html.render(Page.model)
        }
      }
    } ..... other routes


loggedInUserディレクティブは件名を抽出し、それが認証されているかどうかを確認する必要があります。それ以外の場合は、ログイン フォームにリダイレクトします。SubjectUtils.getSubject.getPrincipal問題は、ログに正しいアカウントが表示されているにもかかわらず、常にログインフォームにリダイレクトされることです。

更新しました

実際、Spray は Akka の上に構築されています。getSubjectしたがって、問題は現在 ThreadLocal 環境に依存している実装の背後にあると思います。Shiro + Akka のトピックを検索しましたが、役立つ情報は見つかりませんでした。

4

2 に答える 2

7

これは間違いなく可能ですが、Subjectメッセージを処理している Akka コンポーネント (アクター) が を利用できるようにする必要があります。

私は Akka のアーキテクチャ (アクター / メッセージング モデル) には精通していますが、Akka 自体を使用したことがないため、次の回答を最良の推測としてください。

従来の Shiro ベースのアプリケーションや Web アプリでは、現在の呼び出し元やリクエストを反映するインスタンスを構築し、それを現在実行中の にバインドする役割を果たします。これにより、そのスレッドの実行中の後続の呼び出しが正しく機能することが保証されます。これはすべて、Shiro の Subject ドキュメントに記載されています( Subject.BuilderおよびThread Associationセクションを参照してください)。SubjectThreadSecurityUtils.getSubject()

たとえば、Web アプリでは、ShiroFilterこのセットアップ/バインド/バインド解除ロジック がServletRequestごとに自動的に実行されます。Akka ベースのアプリケーションの何か (何らかの「フレームワーク」コードまたはコンポーネント) が同じセットアップ/バインド/アンバインド ロジックを行うのではないかと思います。

Akka では、上記のドキュメントで説明されているように、従来の Thread ベースのアプローチを使用できると確信しています (Play! ユーザーはこれを成功させたと思います)。しかし、別の興味深いアプローチが Akka の不変メッセージで利用できる可能性があります。

  • メッセージが構築されると、Shiro PrincipalCollection や認証状態 (認証されているかどうか) やその他のもの (runAs 状態など) などのサブジェクト固有の情報 (メッセージ「ヘッダー」など) をメッセージに添付できます。

  • 次に、メッセージが受信されると、その情報が への入力として使用されSubject.Builderてインスタンスが作成されSubject、その Subject インスタンスがメッセージング処理中に使用されます。ShiroSubjectインスタンスは非常に軽量で、リクエストごとに (または必要に応じてリクエストごとに複数回) 作成および破棄されることが期待されるため、Builder のオーバーヘッドについて心配する必要はありません。

  • が構築されたらSubject、現在実行中のスレッドにバインドしてからアンバインドするか、メッセージを処理する各アクタが「フレームワーク」のような方法でこの同じロジックを通過することができます。サブジェクトの状態がスレッド レベルではなくメッセージ レベルで維持されるようになったため、この後者のアプローチではスレッド バインディングはまったく必要ありません。

この代替 (スレッドベースではない) アプローチの証として、ActiveMQの今後のShiro プラグインは、スレッドではなく接続状態を使用して Shiro 状態を保存します。同様に、メッセージ状態も同様に簡単に使用できます。

非スレッドベースのアプローチでは、ダウンストリームの呼び出し元が呼び出してインスタンスSecurityUtils.getSubject()を取得できないことに注意してください。Subject彼らは別の「フレームワーク」の方法でそれを取得する必要があります。

繰り返しますが、これは、Akka を自分で使用せずに、メッセージング環境 (Akka など) でこれがどのように機能するかについて、最善を尽くして分析したものです。これにより、ユースケースに関連する方法でこれを解決するのに役立つ十分な情報が得られることを願っています!

于 2013-07-25T16:47:31.517 に答える