3

リクエストが使用している HTTP メソッドに応じて、ロールベースの承認を行う方法を理解するのに苦労しています。私は HTTP 基本認証を使用しており、ユーザーの役割と使用される HTTP メソッドに応じて、要求が成功または失敗するはずです。

例：

  • への GET リクエストはhttp://localhost/rest/、認証されていないユーザーに対しても常に許可する必要があります (匿名アクセス)
  • (同じリソース!)への PUT リクエストは、ユーザーが認証http://localhost/rest/されている場合にのみ許可されるべきです
  • (同じリソース!)への DELETE 要求は、ユーザーが認証され、ロール ADMINISTRATORを持っているhttp://localhost/rest/場合にのみ許可されるべきです

私の現在の（機能していない）設定の試みは次のshiro.iniようになります。

/rest = authcBasic[PUT], roles[SERVICE_PROVIDER]
/rest = authcBasic[POST], roles[EXPERIMENTER]
/rest = authcBasic[DELETE], roles[ADMINISTRATOR]
/rest = authcBasic

アップデート

https://issues.apache.org/jira/browse/SHIRO-107を見つけて、shiro.ini を次のように更新しました。

/rest/**:put    = authcBasic, roles[SERVICE_PROVIDER]
/rest/**:post   = authcBasic, roles[EXPERIMENTER]
/rest/**:delete = authcBasic, roles[ADMINISTRATOR]
/rest/**        = authcBasic

しかし、それでも機能しません。最後のルールだけが一致するようです。また、コミットコメントは、これが許可ベースの承認でのみ機能することを示しているようです。ロールベースの認証に相当する実装はありませんか?

4

2 に答える 2

0

Shiro と REST アプリケーションでも同様の状況がありました。もっと良い方法があるかもしれませんが (SHIRO-107 は見たことがありません)、私の解決策は、Authc フィルター (org.apache.shiro.web.filter.authc.FormAuthenticationFilter) を拡張するカスタム フィルターを作成することでした。authcBasic フィルターまたは Roles フィルターを拡張して、同様のことを行うことができます (ただし、おそらくもっと複雑なので、authcBasic の方が優れていると思います)。

オーバーライドしたいメソッドは「protected boolean isAccessAllowed(ServletRequest request, ServletResponse response, Object mappedValue)」です。引数 (例: "ADMINISTRATOR") は、引数がカンマで区切られた String[] として、mappedValue に入ります。

メソッドとロールの両方の可能性が必要だったので、引数が "-" のようになってしまいました。例えば：

/rest/** = customFilter[削除-管理者]

次のようにして、POST に必要な役割から削除を実行するために必要な役割を分割することができました。

/rest/** = customFilter[DELETE-ADMINISTRATOR,POST-EXPERIMENTER]

これで遊んでいただければ、必要な機能を手に入れることができると思います。

ところで、私は SHIRO-107 を見たことがなかったので、そのテクニックを試したことはありませんでした。おそらく、独自のカスタム フィルターを発明したので試したことはありません。ただし、それは私が行ったよりもクリーンなソリューションを提供する可能性があります。

それが役立つことを願っています!

于 2013-09-16T15:14:20.273 に答える