データベース復習(5)

3161 ワード
JWT cookie Token テキストリンク
0928

1.HTTPプロトコルの特徴

  • 接続なし:クライアント要求に応答するresを送信し、
    • 接続を切断する.
  • ステータス情報なし:通信終了後はステータス情報を保持しない
    • .
    =>レコードが失われています.要求されたユーザーを特定できません.
    =>アイデンティティと権限の特定が困難

    2.認証と認可


    1)認証

  • API要求の利用可能なユーザを決定するプロセス
  • ユーザーがクライアント宣言のユーザーと同じであることを確認
  • リクエストの主体が誰であるかを知るためにhttpメッセージのHeader(Not Body!)要求

    • 2）権限（授権）

  • ユーザーが特定のリソースにアクセスする権限を持っているかどうかを確認する
    • .
  • クライアントが実行したいタスクがクライアント
    • に許可されているかどうか
  • ユーザーはレベル別アクセス権
    • を許可する.
  • の認証を受けると、認証を受けるユーザに特定の権限
    • が付与される.

    3.Cookie/セッション/トークン

  • HTTPプロトコルの不足を補うために使用

    1）クッキー（Cookie）


    resを
  • reqに送信するとともにクッキーの
    • を送信する.
  • クッキーは簡単なkey-valueペアです.クライアントローカルストレージ
  • は、クライアントが最大300個の
    • を格納できる期間のみを格納する.
  • サーバからCookieが受信と、WebブラウザはCookieを保存し、要求されるたびにブラウザは自動的に
    • にCookieを送信する.
  • サーバは、ユーザが要求した情報をCookieとしてクライアントに送信する.
  • Cookieは、要求と応答のHeaderに
    • 格納.
  • ブラウザが閉じても、情報
    • は保持される.
    セキュリティ・ホールは、Butサーバではなくクライアントのローカル・ストレージにあります.

    2)セッション

  • reqが発行すると、サーバエンジンはクライアントに一意のセッションID
    • を提供する.
    ユーザー情報を
  • サーバ(ローカル以外!)に保存します.セッションidのみでクライアントと通信する
    • .
  • は、一定期間、同一ブラウザからの要求を1つの状態とみなし、その状態(Webブラウザが閉じるまで)
    • を保持する.
  • クライアントは、Cookieを使用して送信セッションID
    • を保存する.
  • セッションはサーバメモリに格納され、サーバが再起動するとセッションデータは消失する(メモリリセット)
    • .
  • サーバリソースを使用するため、盲目的に作成するとメモリ使用量が増加し、
    • の速度が低下します.
  • 安全性が良い

    • 3）タグ

  • ステータスなし:クライアントに格納、ステータスなし
  • 拡張性:他のサービスと共有できる
  • ユーザ認証情報は、サーバ、セッション、Cookieに格納されず、サーバ
    • に容易に拡張できる.
    暗号化
  • による情報格納

    • 4. JWT (Json Web Token)

  • トークン
    • は、認証に必要な情報(Jsonオブジェクト)を暗号化する
  • Access Tokenをhttpヘッダに入れてサーバ
    • に送信する.
  • 構造
    • 1) HEADER
- 토큰 타입과 해싱 알고리즘이 들어감(암호화시키는 알고리즘)
1) PAYLOAD
- 토큰에 담을 정보가 들어있음. name과 value로 이루어진 하나의 정보(claim)
- 등록된/ 공개/ 비공개 클레임 존재
- iss:토큰 발급자
- exp:토큰 만료시간
- iat:토큰이 발급된 시간. 토큰의 age가 얼마나 되었는지 판단 가능 =>시간은(numericDate형식)
3) SIGNATUER
- 토큰의 유효성 체크 (secret key 이용)를 위해 서명 검증
- 최초 만들때 signature 에서 scret key를 만드는데 짝퉁은 signature 에서 차단
  • Refresh Token
    -Access Token(JWT)を使用して認証を行う方法は、第三者によって盗まれた場合にセキュリティ保護を受けやすい
    -トークンの有効期間が長い場合は、セキュリティ上の問題があります.逆に、時間が短い場合は、常にログインする必要があります...
    -refresh tokenはAccess Token形式と同じ(約2週間の有効期間)
    -accesstokenが期限切れになったときに再発行
    -初期ログイン時にアクセスtokenが同時に発行されます

    • 5.Tokenによるサーバ通信実験


    昨日行ったMongoDBルータとコントローラに追加

    1)JWTによるモジュール化



    (1)create:タグ戻りを作成し、パラメータとしてペイロードを受信する(ペイロードはuserIdとname)
    (2)verify:生成したトークン値をパラメータとして受信し,暗号化を解放して返す.エラーが発生した場合は、エラーのタイプに応じて-1、-2、-3の値を返します.

    2)authModuleを作成し、検証が必要なタスクをミドルウェアとして使用


  • というBoardという集合をアップロード、修正、削除する場合、ユーザIDはパブリッシャIDと同じである必要がありますので、認証する必要があります.
  • ヘザー値に、承認/値:AccesToken値、req
    • と入力します.
  • tokenでエラーが発生した場合、エラーのタイプに応じてミラーメッセージを出力するように設定されます.
  • userInfoという変数を作成し、トークンの復号化されたuserIdを入れます.
  • 以降、関数の結果をreqに書き込み、コントローラに移動
    3)以降のコントローラにおいて、復号されたトークン値のUserInfoとmongodbに記憶されているIDが一致していることを確認する
    4)一致する場合post/update/delete機能を実行します.
    5)一致しない場合、エラーメッセージ(「アクセスなし」)が表示されます.
    • uni-appで左側のナビゲーションバー効果を実現
    JAva逆シーケンス化-Transformerクラスが悪意のあるコードを実行できる原理