問題タブ [shiro]

someController/someAction?param1=aa¶m2=bb のような uri があります

このuriからコントローラー名とアクション名を抽出できるgrailsの方法はありますか。

またはshiroには、このuriが許可されていることを検出する方法がありますか?

私はドメイン メニュー (名前、URL) を持っており、現在のユーザーに許可されているメニュー リストを取得したいと考えています。

/auth/login (user:login としてマッピングされている可能性があります)、/user/login などの URL

だから2日前に私はこの質問をします。

メニューを (name,controller,action,param) に変更し、メニューリストを次のようにフィルタリングします。

下手な英語で申し訳ありません。返信ありがとうございます。

ところで、shiro をキャッシュする方法に関するもう 1 つの質問があります 。grails shiro でキャッシュ権限を使用する方法

大量に: メニューリストを保存するより良い方法は何だと思いますか? 原因：

1. ユーザーの権限により、ユーザーに異なるメニューを表示する必要があります。
2. ときどき webapp を更新しますが、後でユーザーにメニューを表示したいとします。そのため、menu.visible などを変更するだけです。(ハード コードの cfg やソースを変更するよりも優れています)。
3. メニューを表示するためにextjsを使用しています（そのため、navプラグインは使用できません）。

を呼び出すたびsubject.isPermitted()に、SQL が db に送信されます。
どうすればキャッシュできますか? 例はありますか？ありがとう。

shiro grails プラグインのドキュメントを読みましたが、理解できません。

情報源：

cachemanager を shiro に設定するには? spring.resource を試すと、エラーがスローされます。

cachemanager のインスタンス Bean 名は何ですか? 他にsthを設定する必要がありますか?

authc フィルターを使用するように URL を構成する方法を示す例はたくさんありますが、適切な単純なログイン ページの例は見つかりません。私は Shiro への Spring 統合を使用していますが、私の問題とは関係がないと思います。

ドキュメントを読んで、次のようにフィルター ファクトリをセットアップしました。

xml ファイル全体は割愛します。これを行うと、次のようになるため、適切なフィルターが選択されていることがわかります。

私はこの応答を受け取ります：

これまでのところ、とても良いですよね？ただし、ユーザー名とパスワードを送信すると、Reports.jsp のコンテンツを取得する必要がありますよね? 私はしません。これを行うと: * curl -v -d "username=demo&password=demo&rememberMe=false" http://localhost:8080/factorlab-web/Reports.jsp

以前と同じ応答が得られます。

明らかに、構成について、またはそれがどのように機能するかについて、私は混乱しています。最初に、2 番目の curl コマンドから何が期待できるか、または期待どおりに表示されない理由を誰か教えてもらえますか?

2 番目に、login.jsp (または同様のもの) を使用した小さなサンプルがあり、ユーザーが次の場合に何が起こるかを確認できます: * 明示的にログイン ページに移動する * 自動的にログイン ページに誘導される元の試みられたページ）。* ログイン ページから間違ったユーザー名とパスワードを送信します。

I'm looking at using Apache Shiro as a central authentication service for all our applications over a variety of platforms.

It's hinted at that it can integrate with a variety of platforms which would be ideal for my purposes but I cannot find any examples of how this is achieved from .NET (ASP.NET MVC specifically if it makes any difference).

Does anyone know where I can find an example of how to do this?

私はしばらくの間JMXを勉強してきましたが、行き詰まっています。

JMXを介してリモートクライアントに一部の機能を公開するアプリケーションがありますが、ほとんどの場合、既存のセキュリティ機能で十分ですが、アプリケーションはセキュリティバックエンドとしてApacheShiroフレームワークを使用します。

私の問題は、サーバー側でクライアントデータを収集する方法がないことです。Shiroは、クライアント（サブジェクト）を識別する方法を必要としています。通常、実行中のスレッドはサブジェクトに関連付けられていますが、オンラインのJMXドキュメントには、リモートJMXのスレッドモデルに関する手がかりはあまりありません。

クライアントをスレッドに関連付けるにはどうすればよいですか、または相互作用するMBean内のクライアントデータを取得する方法はありますか？

Jersey で REST API を開発しており、依存性注入に Google Guice を使用し、セキュリティ フレームワークとして Apache Shiro を使用したいと考えています。

認証のために、EntityManagerに接続されているカスタムAuthenticatorを注入する必要があるカスタムRealmを作成しました。

ただし、依存関係はレルムに注入されません。shiro.ini (使用される領域を定義する必要があります) は、guice によって管理されていないと思います。

依存関係を Apache Shiro、特に使用されている Realm に注入するにはどうすればよいですか?

私の web.xml には、guice にマップされたフィルターしかありません

私の GuiceServletConfig は、CustomRealm を含むすべての依存関係を構成します

白鬼は領域のみを定義する

私は現在Javaベースのセキュリティフレームワークを評価しています。私はSpring3.0ユーザーなので、SpringSecurityが正しい選択であるように見えましたが、Springセキュリティは過度の複雑さに苦しんでいるようで、セキュリティの実装を容易にしているようには見えません。シロはもっと首尾一貫していて理解しやすいようです。これら2つのフレームワーク間の長所と短所のリストを探しています。

JSF 2.0 で Apache Shiro を使用するための参照プロジェクトまたはガイドを知っていますか?

BR カール

プラグインで動作するようにアプリを構成する正しい方法を見つけるのが非常に難しいと感じています。grails 1.3.6 と Shiro プラグイン 1.1.3 を使用しています。

プラグイン ドキュメント サイトのクイック スタート ガイドに従ってアプリケーションをセットアップしましたが、さらに構成したい場合、つまりログイン成功 URL を設定したい場合、障害にぶつかっています。

私が理解していないのは、調査の結果、オプションを設定する3つの方法があることがわかりました..

1. config.groovy で明示的なオプションを 1 行として設定する、つまり security.shiro.redirectUrl = "/blah"

2. nabble と Stack Overflow でこのタイプのブロックをよく見かけますが、どこに行くかについてのヒントはありません。

   security { shiro { filter { successUrl:"/blah/" } } }

このアプローチを試して successUrl を設定しましたが、効果はありません。

1. SecurityFilters.groovy ファイルへの参照を見てきましたが、このファイルのどこに successUrl を配置するのかわかりません..

だから誰かが私のためにこれを片付けることができれば、それは素晴らしいことです:-)

ありがとう、

独自の MVC と承認モデルに基づく Web アプリケーションでは、最近 Spring MVC に移行しました。その動きの一環として、ローカルで作成された GUID から、各要求と共に Cookie ベースのセッション ID に渡されることも検討しています。

一見すると、私たちのケースでは、標準の JSESSION/HttpSession がすべてのセキュリティ悪の根源であるように見えるため、そうすることは大きな欠点になるように見えます。

1. セッション固定 (既存のコードでは、セッションはログインに成功した後にのみ作成されるため、セッションを無効にする必要はありません。
2. CSRF - セッションが Cookie として渡されることはないため、これは決してリスクではありません (実際のフレームワークや、HDIV および CSRFGuard をチェックした一般的なソリューションがないため、処理に問題があります)。
3. 使いやすさのテスト - QA では、JSESSION では不可能な、複数の役割を持つ複数のユーザーを同じサーバーに簡単に接続できます。
4. さまざまなコンテナ (Weblogic、JBOSS、および Websphere) での一貫した HTTPSession の作成と無効化
5. HTTP から HTTPS に移行するときの JSession 処理の一貫性がありません。

それで、「標準であること」の明らかな利点以外に、なぜJSESSIONルートに行きたいのかについての手がかりはありますか?