shiro shiroとはapacheのオープンソースフレームワークであり、権限管理のフレームワークであり、ユーザー認証、ユーザー認証を実現する.shiroはspringに依存せず、shiroはwebアプリケーションの権限管理を実現するだけでなく、c/sシステム、分散システムの権限管理を実現することができ、shiroは軽量フレームワークに属し、ますます多くの企業プロジェクトがshiroを使用し始めた. アプリケーションの角度でどのようにShiroを使って仕事を完成するかを観察する(図01)iniファイルSubject:本体は、現在の「ユーザー」を代表しており、このユーザーは必ずしも具体的な人ではなく、現在のアプリケーションとインタラクティブなものはすべてSubjectであり、例えばネットワーク爬虫類、ロボットなどである.すなわち抽象概念である.すべてのSubjectはSecurityManagerにバインドされ、SubjectとのすべてのインタラクションはSecurityManagerに委任されます.Subjectを一つの顔と見なすことができる.SecurityManagerこそ実際の実行者です.SecurityManager:セキュリティマネージャ;つまり、セキュリティに関連するすべての操作がSecurityManagerと対話します.すべてのSubjectを管理しています後に紹介する他のコンポーネントとのインタラクションを担当するShiroのコアであることがわかります.SpringMVCを学習したことがあれば、DispatcherServeretフロントエンドコントローラと見なすことができます.Realm:ドメイン、Shiro Realmからセキュリティデータを取得(ユーザ、ロール、パーミッションなど)つまり、SecurityManagerがユーザIDを検証するには、Realmから該当するユーザを取得して比較し、ユーザIDが正当かどうかを確認する必要があります.また、Realmからユーザの対応するロール/パーミッションを取得して、ユーザが操作できるかどうかを検証する必要があります.RealmをDataSource、すなわちセキュリティ・データ・ソースと見なすことができます. shiroアーキテクチャ(図02)3.1 subject:主体、ユーザーであってもプログラムであっても、主体はシステムにアクセスし、システムは主体を認証、授権する必要がある.3.2 securityManager:セキュリティマネージャ、マスターの認証と認可はsecurityManagerで行います.securityManagerは集合で、本当に仕事をしているのはsecurityManagerではなくその中のものです.3.3 authenticator:認証器、主体による認証は最終的にauthenticatorによって行われる.3.4 authorizer:授権器、主体による授権は最終的にauthorizerによって行われる.3.5 sessionManager:webアプリケーションでは一般的にwebコンテナを使用する(ミドルウェアtomcat)sessionを管理し、shiroも一連のsession管理方式を提供している.shiroはweb管理だけでなくcs管理にも使用できるので、webコンテナのsession管理を使用しない.3.6 SessionDao:SessionDaoによってsessionデータを管理し、パーソナライズされたsessionデータストレージに対してsessionDaoを使用する必要がある(tomcatでsessionを管理する場合はSessionDaoを使用せず、分散型の統合管理sessionを使用する場合はSessionDaoを使用します).3.7 cache Manager:キャッシュマネージャで、主にsessionと認可データをキャッシュします.(権限管理フレームワークは主に認証と授権の管理であり、sessionはサーバキャッシュにある)例えば、授権データをcacheManagerでキャッシュ管理し、ehcacheを統合してキャッシュデータを管理する(redisはキャッシュフレームワークである).3.8 realm:ドメイン、領域、データソースに相当し、realmアクセス認証、授権関連データ(元はデータベースから取ったものです).注意:authenticator認証器とauthorizer授権器はrealmに授権と認証を格納するデータと論理を呼び出します.3.9 cryptography:パスワード管理、例えばmd 5暗号化、暗号化/復号化のコンポーネントを提供し、開発が便利です.例えば、よく使われるハッシュ、復号化などの機能を提供します.例えばmd 5ハッシュアルゴリズム(md 5は暗号化のみで復号化されていない).-アカウント/パスワード認証4.Shiro認証(shiro.ini)https://www.w3cschool.cn/shiro/andc1if0.html
小結:認証のステップ1ユーザーID/証明書、すなわちユーザー名/パスワードを収集します.2 Subjectを呼び出す.loginはログインを行い、失敗すると対応するAuthenticationException異常が得られ、異常に基づいてユーザーエラー情報を提示する.ログインに成功しました.3 Subjectを最後に呼び出す.logoutは終了操作を行います.
-zs/ls/ww/adminは同じ操作権限を持っていますか?5.Shiro権限認証(3つの方式の授権をサポートする)5.1プログラミング:if/else授権コードブロックを書くことによってSubject subject=SecurityUtilsを完成する.getSubject(); if(subject.hasRole("admin"){//権限}else{//権限なし}
5.2注記式:実行するJavaメソッドに対応する注記を配置することで完了し、また、対応する例外@RequiresRoles("admin")public void hello()/権限}を投げ出す権限がない
1：shiro ？
5.3 JSP/GSPラベル:JSP/GSPページで相応のラベルで完成する
ライセンス6.1ロールベースのアクセス制御(shiro-role.ini|粗粒度)ルール:「ユーザー名=パスワード、ロール1、ロール2」メソッド:hasRole/hasRoles/hasAllRolesとcheckRoles/checkRoles注1:hasXxxとcheckXxxの違い、hasXxxはbooleanタイプのデータを返し、checkXxxは何も返さないと判断します.検証に成功した場合、次のコードの処理を続行します.そうしないと、例外が放出されます.
6.2リソースベースのアクセス制御(shiro-permission.ini|細粒度)すなわち、まずユーザー名に基づいてロールを見つけ、次にロールに基づいて権限ルール1:「ユーザー名=パスワード、ロール1、ロール2」ルール2:「ロール=権限1、権限2」ルール3:「リソース識別子:アクション:オブジェクトインスタンスID」つまり、どのリソースのどのインスタンスに対してどのような操作が可能か注意:各セクションは記入せずに、デフォルトは*user::tea::stu:: ： isPermitted/checkPermissions
1：permission： ,
2：create,update,delete,view
shiro集積web(shiro-web.ini)7.1 shiro-webを構成する.iniファイル7.2リスナーEnvironmentLoaderListenerによってプロファイルを読み込み、対応するWebEnvironmentを作成する
1： shiroConfigLocations ， shiro
2：shiroConfigLocations “/WEB-INF/shiro.ini”，IniWebEnvironment / WEB-INF/shiro.ini ，
classpath:shiro.ini。
7.3フィルタShiroFilterの構成
1： web.xml
7.4開発中に絶えずプロファイルを修正する
その他8.1不足点ユーザー名/パスワードはiniプロファイルにハードコーディングされ、その後、データベースストレージのように変更する必要があり、パスワードは暗号化ストレージが必要である. ユーザーID Tokenは、ユーザー名/パスワードだけでなく、ログイン時にユーザー名/メールボックス/携帯電話番号の同時ログインを許可するなど、他にもあります.8.2 JUnit 4:Test注記の2つの属性:expectedとtimeout expected属性:所望の放出の異常タイプを示すために使用され、指定した異常タイプを放出すると、テストに合格します.timeoutプロパティ:時間の上限を示すために使用され、テスト方法の時間がこの時間値を超えるとテストに失敗します(タイムアウトしたのはErrors、値が間違っているのはFailuresであることに注意してください) プロファイルxml properties ini[node]key=value