この記事では、承認を制御するためのスプリングセキュリティの方法を紹介し、次のようにそれを共有します。
承認方法を使用して、承認を構成します
各スプリングセキュリティ制御承認式（以下、式と呼ばれる）は、実際にはAPIの承認方法に対応します。これは、要求されたURLアクセス許可が設定されている場合の処理方法です。例えば：
@OverrideProtected void configure（httpsecurity http）throws {http.authorizerequests（）.antmatchers（httpmethod.delete、 "/user/"）.hasrole（ "admin"）.antmatchers（ "/index"）。 .AntMatchers（ "/pay"）。hasanyrole（ "we_chat_pay"、 "ali_pay"）.antmatchers（ "/debug"）。hasipaddress（ "192.168.1.0/24"）;}許可式を使用して、複数の権限のリクエストを承認します
では、いつ承認処理に式を使用する必要があるのでしょうか。セキュリティアプリケーションの許可要件は、多くの場合、複雑で多様です。たとえば、プロジェクトのデバッグ要求は、訪問者が管理者の権利の両方を持ち、会社の内部LANを通じてアクセスする必要があることを期待しています。このような要件では、セキュリティAPIによって提供されるメソッドは、これらの承認方法を継続的に呼び出すことができないという理由だけで満たすことはできません。
認証式を使用して、この問題を解決できます。
@OverrideProtected void configure（httpsecurity http）スロー{http.authorizerequests（）antmatchers（ "/debug"）.access（ "hasrole（ 'admin'）and hasipaddress（ '192.168.1.0/24'）;};}承認表現の例
| 表現 | 説明します |
|---|---|
| PRIMITALL | 永遠に真実を返します |
| Denyall | 偽りを永遠に返します |
| 匿名 | 現在のユーザーが匿名のユーザーである場合、trueを返します |
| 私を覚えてますか | 現在のユーザーが覚えている場合は、trueを返します |
| 認証 | 現在のユーザーが匿名（認証された）ユーザーでない場合は、trueを返します |
| fullauthenticated | 現在のユーザーが匿名でも覚えているユーザーでもない場合はtrueを返します |
| ハスロール（役割） | 現在のユーザー許可コレクションに指定された役割の許可がある場合（一致するとき、指定する権限の前に「role_」が追加されます。つまり、「role_role」許可があるかどうかを判断した場合、trueを返します。 |
| hasanyrole（rofis1、role2、...） | 現在のユーザー許可コレクションに役割許可がある場合はtrueを返します |
| hasauthority（権限） | 現在のユーザー許可コレクションに現在のユーザー権限に権限（「権限」許可があるかどうかに一致するかどうか）がある場合はtrueを返します。 |
| hasanyauthority（権限） | 現在のユーザー許可コレクションに許可がある場合はtrueを返します |
| hasipaddress（ "192.168.1.0/24"） | 要求されたIPマッチを送信するときは、fanhui true |
ロールベースのアクセス制御RBAC（ロールベースのアクセス制御）
おそらく、上記の方法はほとんどのアプリケーションのセキュリティ認証管理を満たすことができると思うでしょう。ただし、実際、エンタープライズレベルのアプリケーションの承認は、多くの場合、データベースデータの動的な変更に基づいています。文字列スプライシングが上で使用される場合、開発者にとって非常に友好的ではないだけでなく（人員の変更は、コードを変更する必要があることを意味します。これは明らかに不合理です）、アプリケーションのパフォーマンスもそれに応じて減少します。それで、それを解決する方法は？
データモデル
一般的なRBACデータモデルには、通常、5つのテーブル（3つのエンティティテーブルと2つの関係テーブル）が必要です。 3つのエンティティテーブルには、ユーザーテーブル、ロールテーブル、リソーステーブルが含まれます。 2つの関係テーブルには含まれます。それらの間の関係は次のとおりです。
RBACデータモデル
ユーザーテーブル
ユーザーはユーザーテーブルを持っている必要があります。企業が人員を変更すると、ビジネス担当者（人事など）がデータテーブルを追加および削除します。
ロールリスト
社長、副社長、部門マネージャーなど、会社にどのようなアイデンティティがあり、会社の特定の状況に基づいてテーブル上でデータを運営するビジネス担当者がいます。
リソースリスト
許可制御が必要なリソースを保存します。制御承認を使用するときに実際にURLを使用するため、ビジネス担当者はURLに従ってデータエントリを整理するのではなく、ビューインターフェイスの形式で動作します。したがって、この表では、ビジネス担当者と権限によって制御されるURLに提示されたメニューとボタンが提示されます。
ユーザーロール関係テーブル
ユーザーテーブルとロールテーブル（ユーザーIDとロールID）の間には、多くの関係があります。ユーザーは複数の役割（ユーザーは部門マネージャーと管理者の両方になることができます）にすることができますが、多くの場合、複数のユーザーに対応します。
ロールリソース関係テーブル
ロールテーブルとリソーステーブル（）も多くの関係です。役割は複数のリソース（ボタンやメニューなど）にアクセスでき、リソースに複数のロールでアクセスすることもできます。
Spring Securityは、このような仕事をするためのカスタム表現もサポートしています
上記はこの記事のすべての内容です。みんなの学習に役立つことを願っています。誰もがwulin.comをもっとサポートすることを願っています。