Uninitialized Sessions

この部分ではresaveとsaveUnifiedの違いは

falseに変換する方法について説明します。

resave: true,
    saveUninitialized: true,

この部分ですsession authentication(인증)を使用すると、発生する可能性のある問題を学習できます.
見えるビスケットを拭き取るリフレッシュすると新しいクッキーがあります.このプロセスは自動的に完了し、DBも保存されています.ビスケットをもう一度拭き取る.リフレッシュ後はCookieがないので.
クッキーを1つもらい、DBも1つ増えました.
これは、アクセスしたすべてのユーザーにCookieとセッションを作成することを意味します.
ユーザーにビスケットを与え、sessionはDBに貯蔵される.
ロボット(偽者)がサイトにアクセスしたり、ログインせずに閲覧したいユーザーがサイトにアクセスしたりした場合.
すべての訪問者に対してCookieおよびsessionが作成され、sessionはすべてDBに格納される.
それはいい考えではない.ログインしたユーザーのsessionのみを保存したほうがいいかもしれません.
匿名のユーザーも気を使う必要はない.ブラウザがバックエンドにアクセスするたびに、DBには、クッキーとsessionが1つずつ貯蔵されている.
もう一度言いますが、これはよくないかもしれません.10万人の訪問者が来ると仮定します.
あなたはその10万人のsessionを創造しますか?では、大きなDBを維持するためには、たくさんのお金がかかります.
解決策はすべての訪問者にビスケットをあげないことです.その必要がないからです.
覚えたいユーザーにだけクッキーをあげます.インターネットで動画を閲覧したいなら
何をしても覚える必要はないのでクッキーをあげる必要はありません
でもログインしたら?その時はクッキーを渡して

だからresaveをfalseに変えました

server.jsから

resave: false,
saveUninitialized: false

saveUninitializedもfalseに変更されました.ブラウザからCookieを削除します.
その後、すべてのセッションをクリアします.入力db.sessions.remove({})db.sessions.find()確認を入力します.DBにセッションは存在しません.
今からサイトにアクセスして、クッキーを受け取ったかどうかを確認します.更新しましたが、ビスケットはあげません.
今はサイトの訪問者なのに、届いていないクッキー.DB度を確認してみます.
ここにもsessionはありません.

saveUninitialized: false,

では、この設定は何を意味しますか?ご覧のように、saveUninitializedはfalseです.

A session is uninitialized when it is new but not modified.

セッションは、新規作成および変更されていないときにUninitializedと呼ばれます.
したがって、変更されていない場合はUninitialized(初期化されていない)という新しいセッションがあります.
では、どこで会話を修正すればいいのでしょうか.セッションは1つの場所でのみ変更できます.userControllerです.ここが会話を修正する場所です.

  req.session.loggedIn = true;
  req.session.user = user;
};

この2行は、実際にはセッションinitialize(初期化)の部分である.これを覚えているからです.
この設定は、セッションを変更するときにのみDBに保存され、Cookieが渡されます.
セッションを変更するのはログイン時のみです.
すなわち、バックエンドは、ログインユーザのみにCookieを提供するように設定される.
匿名ユーザーにビスケットをあげません.
これは良いアイデアで、バックエンドがDBに格納されているのはsession認証の問題の一つです.

解決策の一つはtoken authenticationです。

たとえば、iOSまたはandroidアプリケーションを作成する場合、それらはクッキーを持たないため、tokenを使用します.
しかし、ここでは違います.ブラウザで認証を行うため、Cookieを使用してセッション認証を行うことができます.
もちろん、ブラウザでtokenを使用することはできますが、現在の状況では理解しにくいです.
いずれにしても、session authenticationはブラウザで良好に動作しています.
では、実際に会話を修正してみましょう.ログインしてみてください.
もしそうであれば、ログイン時にCookieが受信され、セッションはDBに保存されます.
ログインしてみました.セッションを受信し、セッションDBにセッションがあることを確認します.loggedInとtrueの情報もあります.
今は覚えたい人だけにビスケットをあげます.それはプレイヤーです.
匿名ユーザーではなく、ログインしている人です.
次のセクションでは表示されますが、このセッションにはより多くの設定があります.

app.use(
  session({
    secret: "Hello!",
    resave: false,
    saveUninitialized: false,
    store: MongoStore.create({ mongoUrl: "mongodb://127.0.0.1:27017/wetube" }),
  })
);

さらにuserがあり、前の部分で述べたように、この部分を保護すべきです.
この部分とsecret部分はコードに表示されないからです.
Webサイトをサーバに配備する場合、URLをここに残すことはできません.DB URLにはDBとusernameがあるからです.
今はまだいいです.passwordは今Mongo URlなので、誰もが違います.
いずれにしても、このような方法でlocalhostをコピーしないほうがいいです.stringを知って接続している人がいるかもしれないので危険です.DB URlもそうです.次のセクションでは、まだ理解されていないsecretがあるので、クッキーをもっと理解します.
たとえば、fieldとDomainと書かれたsessionについて説明します.ExpiresとHttpOnlyもあります.クッキーを構成しているからです
また,コードにはSecureが用いられているが,非表示の方法も分かる.