🍟 ハッシュ＃ハッシュ＃

Hash!
1つの方法は、ハッシュ関数という式にキー値を代入して計算し、計算後の結果をアドレスとして使用して値に直接アクセスすることです.
認証におけるハッシュとは、結局、ある値に「任意の演算」を適用して別の値、すなわち暗号化に変換するプロセスを指す.

🛠 ハッシュアルゴリズムが備えるべき条件

1)すべての値に対してハッシュ値を計算するのにあまり時間がかかりません.
2)ハッシュ値は極力避け,すべての値に一意のハッシュ値を持つ.
3)小さな単位変更であっても,全く異なるハッシュ値を持たなければならない.

🧂 Salt

しかし、実際には、完璧なハッシュアルゴリズムはなく、完璧な暗号化はありません.もちろん、ハッシュ関数は通常、逆関数が存在しない関数として作成されますが、すべての場合の数を記録して追跡することはできません.ハッシュ関数を使用して作成できる値を大量に格納するテーブル레인보우 테이블も存在する...!
だからね.元の値に任意の所定の個別文字列を追加し、既存のハッシュ値とはまったく異なるハッシュ値を返し、アルゴリズムが露出しても元の値を保護します.このとき追加された追加値はsaltと呼ばれます!

▼▼Salt注意事項

saltは繰り返し使用できません.ユーザーアカウントの作成とパスワードの変更のたびに、新しい任意のsaltを使用して復号する必要があります.また、saltはもちろんDBユーザーテーブルに保存されます!

🥠 クッキー

クッキーの勉強を始めたばかりの頃は、認証とともに勉強し、クッキーを세션、토큰のような認証方式と理解していました.しかし、厳密には、Cookieは認証方法ではなく、サーバがクライアントにデータを格納する方法です.認証の過程で使うだけです!
HTTP Cookie(Web Cookie、ブラウザCookie)は、サーバがユーザWebブラウザに送信するデータのほんの一部である.ブラウザは、これらのデータ・セグメントを保存し、再要求を要求すると、同じサーバに送信します.Cookieは主に2つのリクエストが同じブラウザから来たかどうかを決定するために使用されます.これにより、ユーザーはログイン状態を維持できます.これは,無状態HTTPプロトコルが状態情報を記憶するためである.
Mozock Cookieでは、サーバがクライアントにデータを転送して保存したり、再インポートしたりすることができます.(また、Cookieを単独で削除しない場合は、保持し続けます.)もちろん、サーバはいつでもクライアントから情報を取得できません.これらの条件を体現しているのはCookieオプションです!

🍫 Cookieオプション

// example
    cookie: {
      domain: 'localhost',
      path: '/',
      maxAge: 24 * 6 * 60 * 10000,
      sameSite: 'none',
      httpOnly: true,
      secure: true,
    },

ドメイン:Cookieのドメインオプションがサーバのドメインと一致している場合にのみ、Cookieを転送できます.

Path:Cookieのpathオプションがサーバの詳細パスと一致した場合、Cookieを送信できます.

MaxAgentまたはExpires:Cookieの有効期間設定

HttpOnly:スクリプト内のクッキーにアクセスできるかどうかを決定し、falseに設定されている場合は、スクリプトラベルを使用してクッキーにアクセスできます.△XSSの攻撃を受けやすいので、敏感な個人情報を含まないほうがいい.

セキュリティ:このオプションがtrueに設定されている場合、Cookieはhttpプロトコルでのみ転送できます.

Samesite:CORSリクエストに対してCookieを送信するかどうかは、オプションとメソッドによって異なります.(Lax-GETメソッドのCookie転送のみ、Strict-CrossOriginのCookie転送ではなくSameSiteのCookie転送のみ、常にCookie転送を行う必要はありませんが、Cookieオプションのsecureオプションを有効にする必要があります)

.

クッキーをどこに使うんだ?

セッション管理

管理にはサーバに格納されたログイン、カート、ゲームスコアなどの情報が必要です

個人化

ユーザーの好み、テーマなどを設定する

ついせき

ユーザーの動作の記録と分析に使用

🎟 セッション

Cookieは事実自体が認証手段ではないことを観察した.また、クライアントに情報を格納することは、セキュリティにとって強力な選択ではありません.代替案として、セッションベースの認証について説明します.
Cookieがクライアントにデータを格納するのとは異なり、セッションの認証に基づいてサーバにデータを安全に格納します!メッセージをセッションストレージに格納し、セッションIDをクライアントに渡します!明確に、ユーザ認証が成功した状態はセッションに相当し、セッションがアクティブであればセッションIDが発行され、クライアントはセッションIDをセッション成功を証明する手段として使用する.そしてクッキーにこのidだけ保存!
セッションを格納する方法は様々であるが,1)サーバ自体に格納可能,2)ファイルに格納可能,3)データベースに格納可能である.1)の欠点は,サーバがシャットダウンすると情報がすべて消えてしまうこと,2)同時に修正できないことである.

セッションの基本ロジック

クライアントはIDとパスワードを要求主体に入れ、ログイン後の要求を送信する

    axios
      .post(
        "https://localhost:4000/users/login",
        {
          userId: this.state.username,
          password: this.state.password,
        },
        {
          "Content-Type": "application/json",
          withCredentials: true,
        }
      )

ここでとりあえずwithCrements!基本的に、withCredentialsはCORSオプションです.同じソースでhttp通信を行うと、クッキーは自動的にrequest headerに入ります.しかし、起源が異なる場合ではない.クッキーをヘッダーに手動で入れる必要があります.このとき必要なのはクライアントwithCredentials: true、サーバ側Access-Control-Allow-Credentials : trueです!

ログイン要求を受信したサーバはセッションをアクティブにします。

      req.session.save(function () {
        req.session.userId = userInfo.userId;
        res.json({ data: userInfo, message: "ok" });
      });

Session.save(callback)

このメソッドは、セッションをリポジトリに保存し、リポジトリ内のコンテンツをメモリ内のコンテンツに置き換えます.セッションをショップに保存すると、コールバックに渡される関数が実行されます.この方法を使用しないと、リダイレクトがセッション・ストレージにデータを保存するよりも早く実行され、ログイン・ステータスが保持されないというエラーが発生する可能性があります.

サーバは、後でリクエストを受信したときにセッションをチェックし、検証します。

    if (!req.session.userId) {
      res.status(400).send({ data: null, message: "not authorized" });
    } else {
      const result = await Users.findOne({
        where: { userId: req.session.userId },
      }).catch((err) => res.json(err));

      res.status(200).json({ data: result, message: "ok" });
    }

CookieとSession、稲妻比較!

はどこに保管されていますか?Cookieはクライアントであり、セッションはサーバ

である.

の長所は?Cookieはサーバに負担をかけず、セッションは信頼できるユーザーであり、サーバ上でさらに検証することができます.(より安全)

の欠点は?Cookie自体は認証ではなく、セッションは分散

に不利である.

コメントドキュメント

開発者キニーのブログ