[Shiro] 認証・認可の許可文字列と関連内容

1. 許可文字列

1.フォーマット

リソース:権限:操作
(一般的な形式は次のとおりです:モジュール:機能:操作）

リソース: システム内で保護する必要があるオブジェクト、データ、またはサービスを指します。リソースは、一般的な用語または特定のオブジェクトの場合があります。
権限:リソースに対する操作または機能を指し、リソースへのアクセスと使用を制限するために使用されます。許可には動詞または説明的な単語を使用できます。権限が何を行うのか、または何を行うのかを正確に表す必要があります。
操作: CRUD など、特定の権限に対応する特定のアクションの実行を指します。

ワイルドカード ( *) は 1 つ以上を表します。

単純なワイルドカードも使用できます。たとえばsys:user:*、として省略することをお勧めしますsys:user(フロントエンドの区切りにアスタリスクは使用できません)。例
1 は、またはで始まるすべてのアクセス許可文字列と正常に一致します。例 2 は、で始まるすべてのアクセス許可文字列と正常に一致します。またsys:usersys:usersys:user:
syssyssys:

2. 具体例

モジュール:関数:操作
例 1:sys:user:editデリゲートシステムモジュール: ユーザー機能: 編集操作
例2：report:couponReceive:*代表者レポートモジュール：クーポン収集機能：全操作

3. その他のセパレータ

「/」を区切り文字として使用するリソース間
で権限がどのように分割されるかを示す階層パス。
例えば、posts/view/read
「.」を区切り文字として使用することは、
通常、明確に定義されたオブジェクトまたはリソース階層を持つシステムに適しており、アクセス許可を階層コンポーネントまたは名前空間に近づけることができます。
例えば、posts.view.read

疑問: 上記 3 つの形式 ( :、/、.) ですが、実際の開発ではどの区切り文字を使用する必要がありますか?
回答:個人的な理解ですが、主に最初にシステムがどのように定義されたかに基づいて、どちらを使用しても構いません。また、必要な方を使用しても構いません。

2. 認証・認可の関連内容

1. オーソリティ、URI、URLの違い

パーミッション (permission): 区切り文字の中でも「/」は区切り文字として使用され、URL や URI のスタイルによく似ていますが、主にパーミッションの文字列として使用されます。
URI : リソースを一意に識別します。filterChainDefinitionMapでは、URI はバックエンドリクエストのアドレスまたは静的リソースのパスのいずれかになります。。

URI ワイルドカード:
1. ?: 1 文字と一致します。【任意の文字】
2. *: 0個以上の文字列と一致します。【任意のパス】
3. **: パス内で 0 個以上のパスに一致します。【任意のパスとサブパス】

知らせ：

上に書かれているのはURL (uniform resource locator)ではなくURI (uniform resource identifier )です。両者の間には違いがあります:
URL は URI のサブセットである特定の URI です。リソースを一意に識別するだけでなく、このリソースを見つけるための情報を提供します。URI は意味論的な抽象概念であり、絶対的または相対的であることができますが、URL は検索に十分な情報を提供する必要があり、絶対的です。

簡単に言うと、
URI : ID 番号(その人がいるということだけがわかるが、それが誰なのかはわからない)
URL : ID アドレス + 名前(その人が誰であるかがわかるだけでなく、その人を見つけることもできる
)リソースを一意に表現できるものであればURIとなり、URIに基づいてリソースへのアクセス方法がURLとなります。
上記参考：
URIとURLの違いと関連性

実際の開発では、パーミッション（許可）とURIを組み合わせて使用します。

@Bean
public FilterChainDefinitionMap createFilterChainDefinitionMap() {
    
    
    Map<String, String> filterChainMap = new LinkedHashMap<>();
    filterChainMap.put("/public/**", "anon");
    filterChainMap.put("/admin/**", "authc,roles[admin]");
    filterChainMap.put("/**", "authc");
    return new DefaultFilterChainDefinitionMap(filterChainMap);
}

上記の例では、/public/**パス( anon)、パスの
下の URI を認証とアクセス許可を必要とするように設定し ( )、他のすべてのパスの下の URI を要求するように設定します。 ( ) にアクセスします。/admin/**adminauthc,roles[admin]
authc

2. 認証・認可フィルター名

1. 認証フィルター名

anon: ログインせずにリソースにアクセスできることを示します

user: ユーザーがリソースにアクセスするにはログインする必要があり、ログイン時にチェックしないことを示します ()

authc: リソースにアクセスするにはログイン認証が必要であることを示します。通常、ログインインターフェイスに使用されます。

2. 認可フィルター名

perms: たとえば/public/**=perms[user:add:*]、複数のパラメータを記述することができ、複数のパラメータがある場合は引用符を追加する必要があり、パラメータはカンマで区切る必要があります。たとえば、複数のパラメータがある場合は、各パラメータを渡す前に渡す必要があります/public/**=perms["user:add:*,user:modify:*"]。 isPermitedAll() メソッドと同等です。

roles: たとえば/admin/**=roles[admin]、 ; パラメータは複数記述できますが、複数ある場合は引用符を追加する必要があり、各パラメータはカンマで区切る必要があります。たとえば、複数のパラメータがある場合は、各パラメータが渡されます/admin/**=roles["admin,guest"]。 hasAllRoles() メソッドと同等です。

3. 認可方法

主に次の 4 つのタイプがあります。

プログラムによる: if/else コードブロックを使用して実行されます。

アノテーション: 実行されたメソッドに対応するアノテーションを配置することで完了し、権限がない場合は対応する例外がスローされます。

ビューページ: ビューページ (Beetl/JSP) 内の対応するタグによって完了します。

URI ベースのインターセプト: URI の照合に基づいてアクセス権を決定します。

以下では主にアノテーションとURIベースのインターセプトについて紹介します。

1. プログラムによる (データに固有)

シナリオ: 編集と監査でリソースを共有するリソースに対する監査権限があるかどうかを判断し、対応する操作を実行する具体的な適用
例:リスト内の特定の項目やデータの種類に対する操作権限があるかどうか

Subject subject = UserUtils.getSubject();
subject.isAuthenticated();            // 是否身份验证授权通过
subject.isPermitted(permission);      // 验证权限字符串
subject.isPermittedAll(permissions);  // 验证权限字符串全部通过
subject.hasRole(roleIdentifier);      // 验证是否有角色权限

2. 注釈 (きめ細かい)

シナリオ: URL リソース、ボタン、およびその他の操作に対して権限フィルターを実行します。ユーザーがインターフェイスの検証をスキップした場合、URL アドレスに直接アクセスする場合にも権限の検証が必要になります。
~~例: ユーザーはユーザー管理権限を持っています (ただし、どのユーザーが管理されるかは指定されていません)~~
具体的なアプリケーション例: 現在のユーザーがユーザーを追加する権限を持っているかどうか (インターフェースの追加を要求できるかどうか)

コントローラーメソッドに次のアノテーションを指定します。

@RequiresPermissions (value={“sys:user:view”, “sys:user:edit”}, logical= Logical.OR): 現在のサブジェクトに user:view または user:edit 権限が必要であることを示します。

@RequiresRoles(value={“admin”, “user”}, logical=Logical.AND): 現在のサブジェクトには管理者とユーザーのロールが必要であることを示します

@RequiresAuthentication: 現在のサブジェクトがログインによって認証されていることを示します。

@RequiresUser: 現在の対象者が私を記憶することで認証またはログインされていることを示します。

@RequiresGuest: 現在の対象者が本人確認を行っていない、または私がログインしたことを覚えていること、つまり旅行者 ID であることを示します。

3. URI ベースのインターセプト (粗粒度)

シナリオ: プログラミングやアノテーションなどを使用して権限をフィルタリングするのが不便な場合は、URI を使用して権限を制御したり、URI アドレスの権限をグローバルに制御したりできます。例: ユーザーは部門 A (部門 A のユーザーのみ) を変更できます
~~。部門 B と部門 C は変更できません)~~
特定のアプリケーション例: 現在のサブジェクトに特定のページへのアクセス許可があるかどうかを判断する

形式:
URI地址及通配符 = 过滤器名称（支持多个，用英文逗号分隔并加双引号）
上記の権限フィルター定義の構成は、上から下への最初の一致優先の原則に基づいており、正常に一致した URI が優先され、ワイルドカードがサポートされます。

3. 補足: 粗粒度の権限と粒度の細かい権限とは何ですか?

粗粒度: リソースタイプの管理は粗粒度のアクセス許可制御と呼ばれます。つまり、メニュー、ボタン、メソッドのみを制御します。

詳細: リソースインスタンスの制御は詳細な権限管理と呼ばれます。つまり、データレベルで制御される権限です。