序文
Angularは単一ページのアプリケーションであるため、ほとんどのリソースは最初からブラウザにロードされるため、検証のタイミングにもっと注意を払い、検証に合格したユーザーのみが対応するインターフェイスを確認できるようにする必要があります。
この記事の認証は、ユーザーがログインしているかどうかを判断し、サーバーとのすべての通信でサーバーの検証ニーズを満たすことができることを確認する方法を参照しています。特定の権限があるかどうかについての判断は含まれていないことに注意してください。
ログインの場合、主にユーザーのユーザー名とパスワード入力を受け入れ、検証のためにサーバーに送信し、検証応答を処理し、ブラウザ側の認証データを作成します。
ID認証を実装する2つの方法
現在、ID認証を実装する方法には2つの主要なカテゴリがあります。
クッキー
従来のブラウザのWebページは、Cookieを使用してIDを確認します。実際、ブラウザのアプリケーションレイヤーでは、基本的にIDの検証を心配する必要はありません。 Cookieの設定はサーバーによって完了します。リクエストを送信すると、ブラウザは対応するCookie情報を自動的に添付します。したがって、JavaScriptコードでは、このために特別なコードを記述する必要はありません。しかし、私が要求するたびに、私はすべてのCookieデータを持ってきます。
CDNの適用とモバイルデバイスの徐々に上昇することで、Cookieは複雑でマルチドメイン認証のニーズを満たすことができなくなります。
鍵
実際、キーベースの認証は最近登場しただけでなく、Cookieの歴史よりも長くなっています。ブラウザがサーバーを要求すると、リクエストのヘッダーなど、特定の方法でキーをリクエストのキーを添付します。これを行うには、管理のために特別なクライアントコードを作成する必要があります。
最近登場するJSONベースのWebキー（JSON Web Token）標準は、キーを使用した典型的な認証です。
Webアプリケーションでは、APIを構築している場合は、重要な方法を使用することを優先する必要があります。
プロセスログイン
ログインは、ID検証の最初のステップです。ログインすることによってのみ、対応するID検証データを編成できます。
別のログインページを使用する必要がありますか？
ログインページに対処するには2つの方法があります。
ログインが完了した後、別のログインページがシングルページアプリケーションにジャンプします。これにより、単一ページアプリケーションのリソースのアクセス制御が可能になり、非ロジンユーザーがアクセスできないようにし、バックグラウンドまたは管理ツールのアプリケーションシナリオに適しています。しかし、それは実際にシングルページアプリケーションのユーザーエクスペリエンスを削減します
単一のページアプリケーションのデザインコンセプトに沿った単一ページアプリケーション内でログインを実行し、悪意のある人はいつでもシングルページアプリケーションのフロントエンドコードを取得できるため、人気のある製品シナリオにより適しています。
別のログインページ
一般的に言えば、別のログインページを使用する目的は、ログイン後にジャンプしたページを匿名のユーザーがアクセスするのを防ぐことです。したがって、ログインページではフォームが作成され、従来の称賛の提出方法（非ajax）が直接使用されます。バックエンドがユーザー名とパスワードを正常に検証した後、ログインが出力された後、片面アプリケーションページのHTMLが正常に検証されました。
この場合、認証情報を出力HTMLに直接配置できます。たとえば、 Jadeを使用して次のようなページを作成できます。
<！ - dashboard.jade-> doctype htmlhtmlhtml head link（rel = "styleSheet"、href = "/assets/app.e1c2c6ea9350869264da10de799999dced1.css"）ボディスクリプト。 window.token =！{json.stringify（token）}; div.md-padding（ui-view）スクリプト（src = "/assets/app.84b1e53df1b4b23171da.js"）ユーザー名とパスワード検証が成功した後、バックエンドは次の方法を使用してHTMLをレンダリングおよび出力できます。
RESTRES.RENDER（ 'Dashboard'、{token：token}）;Angularアプリケーションが起動すると、認証と通信できます。また、ログインして正常にログインしたユーザーのみがこのページを入力できるようにします。
単一ページアプリにログインする組織
マルチビューAngularアプリケーションでは、通常、ルーティングが使用されます。ページ内には、通常、固定サイドバーメニューまたはトップナビゲーションメニューがあり、テキスト領域はルーティングモジュールによって制御されます。
次のサンプルコードでは、角度材料を使用してページを整理し、ルーティングモジュールはUIルーターを使用します。アプリケーションが開かれると、特別なロードアニメーションがあります。読み込みが完了すると、表示されたページはAppControllerコントローラーによって使用されます。ログインしていないユーザーの場合、ログインフォームが表示されます。ログインが完了した後、ページは3つの部分に分割されます。1つはトップパンムナビゲーション、 2つ目はサイドバーメニュー、もう1つはルートコントロールの主要部分です。
コードは次のとおりです。
<body ng-app = "app" layout = "row"> <div id = "loading"> <！ - ページの読み込みプロンプト - > </div> <div flex layout = "row" ng-cloak ng-controller = "appcontroller" ng-init = "load（）load（）" "> <div ng-if =" </div> <div ng-if = "isuserauth" flex layout = "row"> <md-sidenav flex = "15" md-is-locked-open = "true"> <！ - sidebarメニュー - > </md-sidenav> <md-content flex layout = "columm" columm "colum =" main "main> <md-tookar> <md-content> <！ - ルーティング - > <div ui-view> </div> </md-content> </md-content> </div> </div> </body>
アニメーションをロードするために、それらはAppController外側にあり、 AppControllerコードに隠すことができます。これにより、すべてのCSS/JavaScriptがロードされた後、ロードが消えるという目的が達成されます。
AppControllerには変数がありますisUserAuth初期化するとfalseです。ローカルに保存されたセッション情報が有効である場合、またはログインが完了した後、この値は設定tureます。 ng-ifの制御により、ログインフォームを隠し、アプリケーションコンテンツを表示する目的を実現できます。ここではng-show/ng-hideの代わりにng-ifを使用することによってのみ、前者は本当にdom要素を削除して追加することに注意する必要がありますが、後者はDOM要素のCSS属性のみを変更することに注意してください。これは非常に重要です。この方法でのみ、ログインした後、単一ページアプリケーションのコンテンツがロードされてログインする前に現在のルートのコントローラーコードが実行されないようにすることができます。
クライアントがパスワードを暗号化する理由
ユーザー名とパスワードに基づく理想的なログインプロセスは次のとおりです。
1.ブラウザ側は、ユーザーが入力したパスワードを取得し、MD5などのハッシュアルゴリズムを使用して、 md5(username + md5(md5(password)))などの固定長の新しいパスワードを生成し、パスワードのハッシュ値とバックレンダーにユーザー名を提出します。
2.バックエンドは、ユーザー名に基づいて対応する塩を取得し、ユーザー名とパスワードのハッシュ値を使用し、暗号文を計算し、ユーザー名とパスワードに基づいてデータベースを検索します
3.クエリが成功した場合は、キーを生成し、ブラウザに戻し、ステップ4を実行します
4.バックエンドは新しい塩を生成し、新しい塩とブラウザから提出されたパスワードハッシュ値に基づいて新しい暗号文を生成します。データベースで塩と暗号文を更新します
おそらく、80％の人がログインがそれほど複雑である理由を理解できないでしょう。これには、明確に説明するために特別な記事が必要になる場合があります。ここでは、まずブラウザがパスワードをハッシュする理由を説明します。理由は次のとおりです。
1.キーレコードを実行することによってのみユーザーの元のパスワードを取得できることを確認するために、ユーザーのパスワードをソースから保護します
2。ネットワークが盗聴され、HTTPSが使用されていない場合でも、盗まれたパスワードはハッシュした後にのみです。これはせいぜいこのサーバー上のユーザーのデータに影響を与える可能性があり、同じパスワードを使用する他のWebサイトには影響しません。
3.サーバーの所有者でさえ、ユーザーの元のパスワードを取得できません。
このアプローチはユーザーにとって最大のリスクをもたらし、現在のアプリケーションのデータが盗まれます。損失範囲は拡張されず、CSDNや他のストリームに問題はありません。
成功した通知をログインします
一部のアプリケーションでは、すべてのページがユーザーがログインする必要があるわけではありません。特定の操作を実行するときにログインするだけでいい場合があります。この場合、ログインした後、アプリケーション全体に通知する必要があります。これにより、ブロードキャスト機能を使用できます。
簡単なコードは次のとおりです。
Angular .Module（ 'app'）.controller（ 'logincontroller'、['$ rotscope'、logincontroller]）; function logincontroller（$ rootscope）{// andoginsuccess（）{$ rotscope。$ broadcast。$ broadcast（ 'user.login.suckess }}他のコントローラーでは、このブロードキャストを聴き、リストや詳細を取得するなど、ログインが成功した後に実行する必要がある操作を実行できます。
$ scope。$ on（ 'user.login.success'、function（handle、data）{// processing}）;ID認証情報
正常にログインした後、サーバーはキーを返し、その後のAPIリクエストはキーをもたらす必要があり、リクエストによって返される応答は、ID情報の無効性に関するエラーであるかどうかを確認する必要があります。この一連の作業は非常に面倒で、自動的に完了する必要があります。
保存
キーを保存するには、ほぼ次の方法があります。
1.cookies：前述のように、これは推奨されません。同時に、4Kの最大制限もあります
2.SessionStorage：タブページは有効です。閉じたり、新しいタブページを開いたりすると、SessionStorageを共有できません。
3. LocalStorage：理想的なストレージ方法。ブラウザのデータがクリーニングされない限り、LocalStorageに保存されているデータは常に存在します。
4。Angular Singleton Service：アプリケーションに保存された場合、データはリフレッシュ後に失われます。もちろん、タブページ間で共有することはできません。
より良いアプローチは、認証情報がLocalStorageに保存されていることですが、アプリケーションが開始されるとAngularのSingletonサービスに初期化されます。
リクエストに認証情報を追加します
アイデンティティ認証情報の目的は、サーバーにIDを示し、データを取得することです。したがって、リクエストには追加の認証情報が必要です。
一般的なアプリケーションでは、認証情報がリクエストのヘッダーに配置されます。各リクエストでヘッダーを1つずつ設定すると、時間がかかりすぎて面倒になります。 Angularの$httpProvider 、すべての要求と応答の統一処理を達成できるインターセプターinterceptorsを提供します。
インターセプターを追加する方法は次のとおりです。
Angular .Module（ 'app'）.config（['$ httpprovider'、function（$ httpprovider）{$ httpprovider.interceptors.push（httpinterceptor）;}]）; HttpInterceptorの定義は次のとおりです。
Angular .Module（ 'app'）.Factory（ 'httpinterceptor'、['$ q'、httpinterceptor]）; function httpinterceptor（$ q）{//リクエストが発行される前に、さまざまな認証情報リクエストを追加するために使用できます。 } config; }、//リクエストが発行されたときにエラーが発生しましたrequesterror：function（err）{return $ q.reject（err）; }、//応答応答：function（res）{return res; }、//バックエンドが応答を返す場合を含む返された応答エラー、非20000のHTTPステータスコードが設定されています。 }};}インターセプターは、リクエストから返品応答までの完全なライフサイクル処理を提供します。これは通常、以下を実行するために使用できます。
1.認証情報の追加など、均一に発行されたリクエストにデータを追加する
2。リクエストが発行されたときのエラー（ブラウザ側のネットワークが接続されていないなど）、および応答が返されたときのエラーを含む統一エラー処理。
3。一部のデータなどのキャッシュなどの統一応答処理など。
4.リクエストの進行状況バーを表示します
上記の例コードでは、 localStorageに値tokenが含まれている場合、各リクエストのヘッドにtoken値が追加されます。
失敗と取り扱い
一般に、バックエンドは、 token検証が失敗したときに応答HTTPステータスコードを401に設定する必要があります。そうすることで、インターセプターresponseErrorで均一に処理できます。
ResponseError：function（err）{if（-1 === err.Status）{//リモートサーバーは反応しません} else if（401 === err.Status）{// 401エラーは一般に認証障害に使用されます。認証が失敗したときにバックエンドによってスローされるエラーに依存します要約します
実際、サーバーによって返されるステータスコードが200でない限り、 responseErrorが呼び出されます。ここでは、エラーを均一に処理して表示できます。
上記のコンテンツは、角度開発アプリケーションのログインとIDの検証に関連しています。 Angularを学ぶことは誰にとっても役立つことを願っています。