appSecurity.xml には次のものがあります。
インターセプト URL パターン="/users/profile/**" アクセス="hasRole('VIEW_PROFILES')".
Intercept-url pattern="/users/profile/edit/**" access="hasRole('EDIT_PROFILES')"
ページ /users/profiles/edit/addnew があり、ロール VIEW_PROFILES を持つユーザーがこのページにアクセスしようとすると、アクセスは成功しますが、ロール EDIT_PROFILES を持つユーザーへのアクセスはブロックされます。
私が間違っていることは何ですか？
"/users/profile/edit/"は より具体的であるため"/users/profile/"、リストの上位に配置する必要があります。
どうして
パターンは常に、定義された順序で評価されます。したがって、より具体的なパターンは、あまり具体的でないパターンよりもリストの上位に定義することが重要です。これは上記の例に反映されており、具体的な /secure/super/ パターンは、具体的でない /secure/ パターンよりも高く表示されます。それらが逆の場合、/secure/ パターンは常に一致し、/secure/super/ パターンは評価されません。
John Farrelly と Ritesh の両方が正しいです。intercept-urlパターンは、リストされている順序で照合されます。一致が見つかるとすぐに、指定された残りのパターンは無視されます。これが、より具体的なパターンを前にリストする必要がある理由です。
あなたの場合、/users/profile/edit/somepageのパターンは最初のパターンで指定されたパターンと一致するintercept-urlため、Spring は問題のユーザーに指定されたアクセス ロールがあるかどうかを適切にチェックします。どうやら、EDIT_PROFILES ユーザーには VIEW_PROFILES 権限がないため、アクセスが拒否されています。同様に、 ../edit/ へのアクセスを EDIT_PROFILES 権限を持つユーザーに制限する意図は、VIEW_PROFILES 権限を持つユーザーにアクセスを許可する前のステートメントによって損なわれています。
簡単な修正のために順序を入れ替えると、おそらく EDIT_PROFILES ユーザーに VIEW_PROFILES 権限 (EDIT_PROFILES 権限に加えて) を付与する必要があります。次に、access="hasAnyRole('REQUIRED_ROLE')"ではなくを使用しaccess="hasRole('REQUIRED_ROLE')"て、アクセス ステートメントを簡略化することを検討してください。
EDIT_PROFILES ルールが VIEW_PROFILES ルールの上にあることを確認してください。VIEW_PROFILES の式を見ると、EDIT_PROFILES に一致するすべての URL が含まれていることがわかります。つまり、VIEW_PROFILES ルールが最初の場合、Spring セキュリティはわざわざ EDIT_PROFILES ルールを試行しません。