認証セキュリティ...クッキー...セッション...
HTTPプロトコル環境は「接続なし、ステータスなし」なので、それをカバーするためにCookieとセッションが必要です.
サーバがCookieを受信すると、Webブラウザ(クライアント)はCookieを推定可能な要求者の情報として保存し、要求されるたびにクライアントはCookieを添付してサーバに送信する.
サーバはリクエストのCookieを読み込むことによってユーザを決定する.<=個人情報の漏洩を防止するため、定期的に削除することをお勧めします
有効期間 ありますキー-値ペア
Cookieを要求されたタイトルに送信する(cookie)
クライアントは、レスポンスタイトル(set-cookie)に汚れCookieを格納します.
ログイン時に「IDとパスワードを保存しますか?」
ポップアップメニューから[今日このウィンドウを表示しない]を選択します.
セッションはCookieベースですが、サーバによってユーザ情報ファイルが管理されます.
サーバは、クライアントを区別するためにセッションIDを付与し、Webブラウザがサーバに接続されてブラウザを終了するまで認証状態を維持します.
もちろん、接続時間に制限があり、応答がない場合は、情報を保持しないように設定できます.
Cookieと比較して、ユーザー情報をサーバに配置することはセキュリティの向上に役立ちますが、ユーザーが多ければ多いほど、サーバのメモリが消費されるスペースが大きくなります.
これは、Webサイトに多数の接続性がある場合、サーバがより大きな負荷に耐え、パフォーマンスが低下することを意味します.
クライアントが要求を送信するとき、セッションIDは、サーバ上のエンジンがクライアントに提供する一意のIDである.
1)クライアントがサーバに接続されると、サーバはセッションidを発行する
2)クライアントがセッションIDをCookieに保存する
3)お客様がサーバに要求した場合、このCookieのセッションIDを要求とともに送信する
4)サーバはセッションIDを受信し、セッション内のクライアント情報を取得する
5)クライアント情報処理サーバ要求を使用してクライアントに応答する
1)クライアント自身にセッションIDを付与
2)セッションidを使用してクライアントにクライアントを区別する情報を提供する
3)Cookieより安全性が優れている
4)ユーザーが多ければ多いほど、使用するサーバーメモリが多くなる
セキュリティ・クリティカル・タスクの実行に使用
セッションはCookieよりもセキュリティ上有利ですが、サーバ上のリソースが使用されているため、セッション数が増えるとサーバのメモリが耐えられなくなり、速度が遅くなる可能性があり、Cookieも有利になります.
クッキー
サーバがCookieを受信すると、Webブラウザ(クライアント)はCookieを推定可能な要求者の情報として保存し、要求されるたびにクライアントはCookieを添付してサーバに送信する.
サーバはリクエストのCookieを読み込むことによってユーザを決定する.<=個人情報の漏洩を防止するため、定期的に削除することをお勧めします
クッキーの特徴
クライアントは、レスポンスタイトル(set-cookie)に汚れCookieを格納します.
const http = require("http")
http.createServer((req, res)=>{
//createServer 메소드의 콜백에서는 req 객체에 담겨 있는 쿠키를 가져온다.
console.log(req.url, req.headers.cookie);
//cookie는 req.headers.cookie에 들어있다. // req.headers는 요청의 헤더
res.writeHead(200, {'Set-Cookie': 'mycookie = test'});
//writeHead 응답의 헤더에 쿠키를 기록하는 메소드
//Set-Cookie: 다음과 같은 값의 쿠키를 저장해라
//여기서는 mycookie = test라는 쿠키를 저장
res.end('Hello cookie');
})
.listen(8083,()=>{
console.log(`8083 포트에서 서버 대기 중입니다.`);
});
Cookie使用例
ログイン時に「IDとパスワードを保存しますか?」
ポップアップメニューから[今日このウィンドウを表示しない]を選択します.
セッション
セッションはCookieベースですが、サーバによってユーザ情報ファイルが管理されます.
サーバは、クライアントを区別するためにセッションIDを付与し、Webブラウザがサーバに接続されてブラウザを終了するまで認証状態を維持します.
もちろん、接続時間に制限があり、応答がない場合は、情報を保持しないように設定できます.
Cookieと比較して、ユーザー情報をサーバに配置することはセキュリティの向上に役立ちますが、ユーザーが多ければ多いほど、サーバのメモリが消費されるスペースが大きくなります.
これは、Webサイトに多数の接続性がある場合、サーバがより大きな負荷に耐え、パフォーマンスが低下することを意味します.
クライアントが要求を送信するとき、セッションIDは、サーバ上のエンジンがクライアントに提供する一意のIDである.
セッションの動作
1)クライアントがサーバに接続されると、サーバはセッションidを発行する
2)クライアントがセッションIDをCookieに保存する
3)お客様がサーバに要求した場合、このCookieのセッションIDを要求とともに送信する
4)サーバはセッションIDを受信し、セッション内のクライアント情報を取得する
5)クライアント情報処理サーバ要求を使用してクライアントに応答する
セッションフィーチャー
1)クライアント自身にセッションIDを付与
2)セッションidを使用してクライアントにクライアントを区別する情報を提供する
3)Cookieより安全性が優れている
4)ユーザーが多ければ多いほど、使用するサーバーメモリが多くなる
セッションの例
セキュリティ・クリティカル・タスクの実行に使用
セッションはCookieよりもセキュリティ上有利ですが、サーバ上のリソースが使用されているため、セッション数が増えるとサーバのメモリが耐えられなくなり、速度が遅くなる可能性があり、Cookieも有利になります.
Reference
この問題について(認証セキュリティ...クッキー...セッション...), 我々は、より多くの情報をここで見つけました https://velog.io/@jeongmin1625/인증보안..-쿠키..-세션テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol