djangoフレームのcookie/sessionの使用例（結び目）
一、http協議は状態問題がない。
httpプロトコルは、複数の要求の間の関連機能を提供していません。協議の真意も、複数の要求間の状態維持を考慮していません。毎回の要求は一回のものとみなされます。しかし、いくつかの場面では、例えば一回のログインで何回もアクセスすると、ログイン状態を保存したいです。プロトコルは直接に会話追跡のサポートを提供していません。他の手段で目標を達成するのを助けなければなりません。
二、会話追跡技術--クッキー
1、クッキーに対する理解 cookieは、維持が必要なデータを保存するためのkey-valueのデータ構造であり、cookieとsessionの最大の違いは、cookieのデータはクライアントに保存され、sessionはデータをサービス端末に保存する。 cookieは、一般にサーバによって設定され、httpの要求ヘッダおよび応答ヘッダに格納されてもよい。 クッキーはブラウザによって保存され、ブラウザはクッキーの保存と送信を実現しました。サーバ上のクッキーの設定と受信は私達の構成が必要です。 は、クッキーを通じて、登録状態データ、履歴アクセス記録、カスタマイズ設定などの必要な情報を複数のセッション間で共有することができ、セッショントラッキングを実現し、ユーザーにウェブサイトが「記録」自身の好みを感じさせ、不要な繰り返し入力を減少させ、ユーザー体験を向上させる。 2、クッキーの使用インターフェース
djangoのサービス端末送信応答には、3つの方法があります。
1.return HttpResonse()
2.return render()
3.return redirect()
これらの3つの方法の実装の結果はいずれもHttpResonseクラスの例であり、cookieを直接設定するために使用することができる。
レスポンスの対象でset_を実行します。クッキー（key，value，…）はクッキーを設定できます。ここで特にクッキー属性の設定に注意します。
クッキーの設定
サーバーが応答対象にセットアップする。クッキー動作は、設定が完了すると、クライアントの後続の要求は、クッキーの属性規則に従ってクッキーデータを搬送することができる。
サーバは要求対象において、request.Cookie辞書データを取得します。ここで得られたcookieデータは安全性から正確性が検証されていません。
注意2：一つのクッキーはkey-valueの項目ですが、まだ属性があります。一つのcookiesは辞書で、多くのcookie項を保存しています。個々のcookie項とcookies辞書全体の関係に注意してください。
3、クッキーの属性
max_メッセージ:
失効遅延時間は、単位が秒で、15秒に設定すると、設定完了後の15秒以内に、このクッキーが有効で、タイムアウト後にクッキーが失効し、ブラウザが失効したクッキーが削除されることを意味します。このパラメータはデフォルトではNoneです。ブラウザが閉じるまで、つまりデフォルトはセッションクッキーです。
注意：max_ならageは0であり、このクッキーをブラウザに直ちに削除させること、すなわちこのクッキーはすぐに無効になることを意味する。
expires:
失効日を指定して、同様に故障クッキーに使用します。別の時間指定方式にすぎません。
domain:
このクッキーはドメイン名の範囲で使用できます。
パス:
domainと配合して使用すると、デフォルトはルート'/'であり、現在のdomainの範囲ではどのurlもこのクッキーを携帯することを意味する。他のパスは、送信範囲を縮小するために自動的に設定されてもよく、したがって、あるクッキーエントリが特定のurlにのみ適用されるように制約される。
secure:
デフォルトはFalseで、httpsプロトコルに合わせて使用されますが、httpsプロトコルでは、Secure属性がTrueのクッキーだけが送信されます。
httponly:
デフォルトはFalseであり、これはjsがdocument.co okieを通じてこのクッキーにアクセスして設定することもできることを意味し、Trueに設定されている場合は、このクッキーにはサービス端末のみのアクセスと設定が許可されることを意味する。
4、クッキーを使う問題
クッキーの安全性問題
サーバは、クライアントから送信されたクッキーの状態判断に基づいて、クライアントに保存されているクッキーデータが非常に容易に修正され、偽装され、サーバはクッキーの正確性をほとんど知ることができず、クッキーのデータを100%信頼することができない。
また、クッキーは盗撮されやすいです。クライアントクッキーに秘密データが含まれていると、より安全ではありません。
クッキーのカバー問題
サービス端末に設定された新しいクッキーは、クライアントにローカルクッキーを更新させる。
クッキーの合理性問題
どのようなデータがクッキーに適していますか？
クッキーのデータは相互作用のたびに伝送されるので、私は次のように思います。は、一般的なデータであるべきです。一般的でないと、帯域幅を浪費して効率を減らすだけです。複数回の相互作用の中で、 を使用したり、修正したりしたほうがいいです。は小さいデータ量の であるべきです。は、非常に秘密のデータであるべきではない。そうでないと、クライアント上で盗撮されやすいか、伝送中に を切り取りやすい。
cookieは特にsessionidを送るのに適しています。上記のすべての条件を満たすことができます。
クッキーの保存問題
cookieはクライアントの一時記憶であり、単一のクッキーファイルの記憶量は最大4 kbと規定されています。各ドメインのクッキーファイルは20個を超えてはいけません。cookieを記憶機能の濫用としてはいけません。クライアント記憶機能を使用するには、locastorgeを有効にする必要があります。
クッキーのアクセス制限問題
jsのdocument.co okieはcookieデータを取得し、コンソールで文字列形式のkey-valueデータを出力します。このクッキーの属性がhttponly=trueであれば、この方法では取得できません。
三、会話追跡技術--session
1、セッションに対する理解
sessionはデータをサーバーに預けて、一つのタグを使ってsession-keyで一意にこのデータをマークします。Session-keyはcookieとしてクライアントに送信します。つまりクライアントはsession-keyだけを保存して、その後、クッキーを通じてサービス端末に送信して、アイデンティティを示すため、sessionはcookieより安全です。
サーバに到着するたびに、cookieに保存されているsession-keyをサーバに取得し、データベースdjango-sessionテーブルで対応するsession-dataを探して、さらに業務ロジックを処理します。
セッションの使用には次のような利点があります。
1、データはサービス端末に保存して、クライアントは一つのsenssionidだけ保存します。
2、sessionidデータ量が少なく、毎回送るのに適しています。
3、安全性、sessionidはランダムな文字列で、いかなる秘密データも携帯していません。
2、セッションの使用インターフェース
セッションの設定
djangoはsessionを実現しました。たくさんの操作を完成してくれました。そして使用するインターフェースを提供するのはとても簡単です。
1、ランダムな文字列をsessionidとして作成します。
2、sessionidをsession-keyとし、session_data辞書はdjango-session表に登録されています。
3、set-cookie、sessionidをクライアントに送信する
注意1：下のソースから見て、session_dataは実は辞書です。そしてormを通じてdjangoに保存します。sessionテーブルには（dict-->strの序列化と暗号化の操作があるべきです。）
注意2：クライアントのクッキーにseesionidが含まれていることが判明したら、このsessionidを使ってこのsessionidに対応するsessionidを更新します。データ
注意3：2人のユーザが同じコンピュータの同じブラウザで同じurlにアクセスすると、Sessionidはクッキーとして存在するため、二人は同じsessionidを使用します。
サーバーにとっては、Sessionidだけは人を認識していません。同じsessionidを使って操作すると、前のデータを上書きして、サービス端末でのsessionidをもたらすことができます。dataデータは互いに上書きされます。このような結果はデータの乱れです。特に二人のデータ項目の数が一致しない場合はもっと深刻です。
セッションの読み込み
sessionを読み込むインターフェースも簡単です。
1、request.Chinesの中のsessionidを取得する
2、sessionidをsessionid_として持つkeyはデータベースのdjango-sessionテーブルに対応するsession-dataを検索します。下の階はormを実行するobjects.filterです。key=sessionid)
3、session-dataのデータを取得し、さらに処理する。
セッションの削除
セッションのインターフェースを削除:
1、del request.session[xxx] # セッションデータのプロパティを削除します。
2、request.session.flush（） # すべてのセッションデータを削除
セッション情報を空にすると次のような操作が行われます。
1、django-sessionテーブルのsession-key=sessionidの記録を削除し、底の操作はormのobjects.filterを実行します。key=sessionid.delete()
2、レスポンスのクッキーのsessionid記録を削除します。
注意1：サーバは、Sessionidをcookieとしてデータをクライアントに送信して保存します。一般的に、セッションクッキーは、ブラウザプログラムを閉じずにセッショントラッキングを維持することができます。しかし、クライアントがブラウザを閉じたら、このsessionidはもう有効ではないです。ただし、djangoからのクッキーのデフォルトの有効時間は2週間ですので、クッキーはクライアントのハードディスクに保存されます。ブラウザを閉じても保存されます。
注意2：クライアントブラウザがいつ閉店するかをサーバが知ることができないため、ブラウザがいつ空のクッキーの操作を行うかが分かりません。クライアントは一般的にロゴアウトの時だけ自動的にsessionの削除を通知します。他の場合はブラウザからの自主的な通知はありませんので、サーバのsessionは無限に保存できません。失効時間を設定させられます。一定の時間内にユーザーが再度このsessionに訪問していないと、サーバー側はこのユーザが失効したと見なされます。さらにsessionデータを削除することができます。
3、セッションの属性
セットニングでは、グローバルのセッション属性を設定することもできます。
1、sessionの正常な仕事はcookieの有効化に依存しています。もしクライアントがcookie機能を無効にしたら、どのようにsessionの正常な仕事を保証しますか？---URLを書き換える
2、同じコンピュータの同じブラウザで同じurlを訪問して、同じsessionidを保存していますが、複数のユーザーが同じsessionidでログインして、データの乱れをどう処理しますか？ユーザー認証コンポーネントを使って、アカウントのパスワードを使って、ユーザーを区別します。
四、まとめ
1、cookieとsessionはhttpプロトコル自体が状態維持をサポートしていない欠点を解決するためです。
2、セッショントラッキングの目的は、複数の要求の間でデータを共有することができ、より良いユーザ体験を提供することである。
3、cookieとsessionはいずれも状態維持データを保存する必要がありますが、cookieはクライアントに保存され、sessionはサービス端末に保存されます。
4、両者の技術の同じ点と違いを分析し研究することは、会話追跡に対する理解と使用を深めるのに役立つ。
以上が本文の全部です。皆さんの勉強に役に立つように、私たちを応援してください。
httpプロトコルは、複数の要求の間の関連機能を提供していません。協議の真意も、複数の要求間の状態維持を考慮していません。毎回の要求は一回のものとみなされます。しかし、いくつかの場面では、例えば一回のログインで何回もアクセスすると、ログイン状態を保存したいです。プロトコルは直接に会話追跡のサポートを提供していません。他の手段で目標を達成するのを助けなければなりません。
二、会話追跡技術--クッキー
1、クッキーに対する理解
djangoのサービス端末送信応答には、3つの方法があります。
1.return HttpResonse()
2.return render()
3.return redirect()
これらの3つの方法の実装の結果はいずれもHttpResonseクラスの例であり、cookieを直接設定するために使用することができる。
レスポンスの対象でset_を実行します。クッキー（key，value，…）はクッキーを設定できます。ここで特にクッキー属性の設定に注意します。
クッキーの設定
サーバーが応答対象にセットアップする。クッキー動作は、設定が完了すると、クライアントの後続の要求は、クッキーの属性規則に従ってクッキーデータを搬送することができる。
def set_cookie(key, value='', max_age=None, expires=None, path='/',
domain=None, secure=False, httponly=False, samesite=None)サーバは要求対象において、request.Cookie辞書データを取得します。ここで得られたcookieデータは安全性から正確性が検証されていません。
@cached_property
def COOKIES(self):
raw_cookie = get_str_from_wsgi(self.environ, 'HTTP_COOKIE', '')
return parse_cookie(raw_cookie)
注意2：一つのクッキーはkey-valueの項目ですが、まだ属性があります。一つのcookiesは辞書で、多くのcookie項を保存しています。個々のcookie項とcookies辞書全体の関係に注意してください。
3、クッキーの属性
max_メッセージ:
失効遅延時間は、単位が秒で、15秒に設定すると、設定完了後の15秒以内に、このクッキーが有効で、タイムアウト後にクッキーが失効し、ブラウザが失効したクッキーが削除されることを意味します。このパラメータはデフォルトではNoneです。ブラウザが閉じるまで、つまりデフォルトはセッションクッキーです。
注意：max_ならageは0であり、このクッキーをブラウザに直ちに削除させること、すなわちこのクッキーはすぐに無効になることを意味する。
expires:
失効日を指定して、同様に故障クッキーに使用します。別の時間指定方式にすぎません。
domain:
このクッキーはドメイン名の範囲で使用できます。
パス:
domainと配合して使用すると、デフォルトはルート'/'であり、現在のdomainの範囲ではどのurlもこのクッキーを携帯することを意味する。他のパスは、送信範囲を縮小するために自動的に設定されてもよく、したがって、あるクッキーエントリが特定のurlにのみ適用されるように制約される。
secure:
デフォルトはFalseで、httpsプロトコルに合わせて使用されますが、httpsプロトコルでは、Secure属性がTrueのクッキーだけが送信されます。
httponly:
デフォルトはFalseであり、これはjsがdocument.co okieを通じてこのクッキーにアクセスして設定することもできることを意味し、Trueに設定されている場合は、このクッキーにはサービス端末のみのアクセスと設定が許可されることを意味する。
4、クッキーを使う問題
クッキーの安全性問題
サーバは、クライアントから送信されたクッキーの状態判断に基づいて、クライアントに保存されているクッキーデータが非常に容易に修正され、偽装され、サーバはクッキーの正確性をほとんど知ることができず、クッキーのデータを100%信頼することができない。
また、クッキーは盗撮されやすいです。クライアントクッキーに秘密データが含まれていると、より安全ではありません。
クッキーのカバー問題
サービス端末に設定された新しいクッキーは、クライアントにローカルクッキーを更新させる。
クッキーの合理性問題
どのようなデータがクッキーに適していますか？
クッキーのデータは相互作用のたびに伝送されるので、私は次のように思います。
cookieは特にsessionidを送るのに適しています。上記のすべての条件を満たすことができます。
クッキーの保存問題
cookieはクライアントの一時記憶であり、単一のクッキーファイルの記憶量は最大4 kbと規定されています。各ドメインのクッキーファイルは20個を超えてはいけません。cookieを記憶機能の濫用としてはいけません。クライアント記憶機能を使用するには、locastorgeを有効にする必要があります。
クッキーのアクセス制限問題
jsのdocument.co okieはcookieデータを取得し、コンソールで文字列形式のkey-valueデータを出力します。このクッキーの属性がhttponly=trueであれば、この方法では取得できません。
三、会話追跡技術--session
1、セッションに対する理解
sessionはデータをサーバーに預けて、一つのタグを使ってsession-keyで一意にこのデータをマークします。Session-keyはcookieとしてクライアントに送信します。つまりクライアントはsession-keyだけを保存して、その後、クッキーを通じてサービス端末に送信して、アイデンティティを示すため、sessionはcookieより安全です。
サーバに到着するたびに、cookieに保存されているsession-keyをサーバに取得し、データベースdjango-sessionテーブルで対応するsession-dataを探して、さらに業務ロジックを処理します。
セッションの使用には次のような利点があります。
1、データはサービス端末に保存して、クライアントは一つのsenssionidだけ保存します。
2、sessionidデータ量が少なく、毎回送るのに適しています。
3、安全性、sessionidはランダムな文字列で、いかなる秘密データも携帯していません。
2、セッションの使用インターフェース
セッションの設定
djangoはsessionを実現しました。たくさんの操作を完成してくれました。そして使用するインターフェースを提供するのはとても簡単です。
request.session['name'] = 'xxx'1、ランダムな文字列をsessionidとして作成します。
2、sessionidをsession-keyとし、session_data辞書はdjango-session表に登録されています。
3、set-cookie、sessionidをクライアントに送信する
注意1：下のソースから見て、session_dataは実は辞書です。そしてormを通じてdjangoに保存します。sessionテーブルには（dict-->strの序列化と暗号化の操作があるべきです。）
注意2：クライアントのクッキーにseesionidが含まれていることが判明したら、このsessionidを使ってこのsessionidに対応するsessionidを更新します。データ
注意3：2人のユーザが同じコンピュータの同じブラウザで同じurlにアクセスすると、Sessionidはクッキーとして存在するため、二人は同じsessionidを使用します。
サーバーにとっては、Sessionidだけは人を認識していません。同じsessionidを使って操作すると、前のデータを上書きして、サービス端末でのsessionidをもたらすことができます。dataデータは互いに上書きされます。このような結果はデータの乱れです。特に二人のデータ項目の数が一致しない場合はもっと深刻です。
セッションの読み込み
sessionを読み込むインターフェースも簡単です。
name = request.session['name']1、request.Chinesの中のsessionidを取得する
2、sessionidをsessionid_として持つkeyはデータベースのdjango-sessionテーブルに対応するsession-dataを検索します。下の階はormを実行するobjects.filterです。key=sessionid)
3、session-dataのデータを取得し、さらに処理する。
セッションの削除
セッションのインターフェースを削除:
1、del request.session[xxx] # セッションデータのプロパティを削除します。
2、request.session.flush（） # すべてのセッションデータを削除
セッション情報を空にすると次のような操作が行われます。
1、django-sessionテーブルのsession-key=sessionidの記録を削除し、底の操作はormのobjects.filterを実行します。key=sessionid.delete()
2、レスポンスのクッキーのsessionid記録を削除します。
注意1：サーバは、Sessionidをcookieとしてデータをクライアントに送信して保存します。一般的に、セッションクッキーは、ブラウザプログラムを閉じずにセッショントラッキングを維持することができます。しかし、クライアントがブラウザを閉じたら、このsessionidはもう有効ではないです。ただし、djangoからのクッキーのデフォルトの有効時間は2週間ですので、クッキーはクライアントのハードディスクに保存されます。ブラウザを閉じても保存されます。
注意2：クライアントブラウザがいつ閉店するかをサーバが知ることができないため、ブラウザがいつ空のクッキーの操作を行うかが分かりません。クライアントは一般的にロゴアウトの時だけ自動的にsessionの削除を通知します。他の場合はブラウザからの自主的な通知はありませんので、サーバのsessionは無限に保存できません。失効時間を設定させられます。一定の時間内にユーザーが再度このsessionに訪問していないと、サーバー側はこのユーザが失効したと見なされます。さらにsessionデータを削除することができます。
3、セッションの属性
セットニングでは、グローバルのセッション属性を設定することもできます。
# settings.py
SESSION_ENGINE = 'django.contrib.sessions.backends.db' # （ ）
SESSION_COOKIE_NAME ＝ "sessionid" # Session cookie key， ：sessionid＝ （ ）
SESSION_COOKIE_PATH ＝ "/" # Session cookie （ ）
SESSION_COOKIE_DOMAIN = None # Session cookie （ ）
SESSION_COOKIE_SECURE = False # Https cookie（ ）
SESSION_COOKIE_HTTPONLY = True # Session cookie http （ ）
SESSION_COOKIE_AGE = 1209600 # Session cookie （2 ）（ ）
SESSION_EXPIRE_AT_BROWSER_CLOSE = False # Session （ ）
SESSION_SAVE_EVERY_REQUEST = False # Session， （ ）
1、sessionの正常な仕事はcookieの有効化に依存しています。もしクライアントがcookie機能を無効にしたら、どのようにsessionの正常な仕事を保証しますか？---URLを書き換える
2、同じコンピュータの同じブラウザで同じurlを訪問して、同じsessionidを保存していますが、複数のユーザーが同じsessionidでログインして、データの乱れをどう処理しますか？ユーザー認証コンポーネントを使って、アカウントのパスワードを使って、ユーザーを区別します。
四、まとめ
1、cookieとsessionはhttpプロトコル自体が状態維持をサポートしていない欠点を解決するためです。
2、セッショントラッキングの目的は、複数の要求の間でデータを共有することができ、より良いユーザ体験を提供することである。
3、cookieとsessionはいずれも状態維持データを保存する必要がありますが、cookieはクライアントに保存され、sessionはサービス端末に保存されます。
4、両者の技術の同じ点と違いを分析し研究することは、会話追跡に対する理解と使用を深めるのに役立つ。
以上が本文の全部です。皆さんの勉強に役に立つように、私たちを応援してください。