事前知識：
1.httpは、ステートレス通信プロトコルである、通信状態は、それ自体に保存されていません
（リクエスト）サーバがルールに従って、本質的に、ユーザの2.webを受信し、ユーザに応答を与える（応答）を要求する責任
3.セッション（セッション）は、すべての通信が同じユーザセッション時間で行われ、独自のWebサーバーで、ユーザーの道を管理するために使用されるWebサーバです
4.cookieは、セッションを実装する方法です
次に入力され、リファレンスドキュメント：フラスコ公式文書
公式が提供する利便性を直接デモコードでは、唯一のログイン機能は、セッションを追加した後、印刷セッションの内容を変更されました
1 app.route（@ ' /ログイン'、メソッド= [ ' GET '、' POST ' ]） 2 デフログイン（）： 3 であれば request.method == ' POST ' ： 4 セッション[ ' ユーザ名' ] =要求。フォーム[ ' ユーザ名' ] 5 プリント（セッション） 6 リターンリダイレクト（なurl_for（' インデックス' ）） 7 戻り ''」 8 <フォームアクション= "" METHOD = "POST"> 9 <P>の<input type =テキスト名=ユーザー名> 10 <P>の<input type = =値を提出するログイン> 11 </フォーム> 12 '」'
以下は、結果の実際の実行時間分析であります
サイトへ1.直接アクセス、ディスプレイがログインしていません
2.アクセス/ログイン、ログインが完了すると
ページショー
サーバーの表示
httpプロトコルパッケージを守って
Requestパケットは、以下の
アップPOSTメソッドでフォームを送信
次のように応答があります
サーバーはクッキーを設定し、リダイレクトパス「/」に戻って302リダイレクト応答を与えます
このとき、ブラウザは、新たな直接ルート、次の要求パケットを要求します
彼は、クッキーの上に置かれています
以下のサーバーの応答
正常な応答200
3.アクセスログアウト
アクセスログアウト、ブラウザに表示さ
閲覧要求パケット
通常、クッキーの要求を運びます
表示応答パケット
また、302リダイレクトを与えられた、だけでなく、クッキーが設定されますが、この時に直接nullに設定されたCookieにされていました
以下リダイレクトコミュニケーション
このとき、ブラウザはすでに要求ではないクッキーを送信します
4.別のブラウザアクセスを使用します
そして、すなわち、ブラウザのChromeブラウザとアクセスを使用
以下の結果をご覧ください。クロム
サーバーは以下の通りです
そして、アクセスにすなわちブラウザを使用
サーバーの表示
対照的にクッキーのシェアはとして表示されていない2つのブラウザは、その後、まだクロムの表示ユーザのログインを使用しているページのクロムを更新します
インデックス機能を変更する、セッションの値を印刷することが可能です
1 @app.route('/') 2 def index(): 3 if 'username' in session: 4 print(session) 5 return 'Logged in as %s' % escape(session['username']) 6 return 'You are not logged in'
刷新chrome与ie
由此可见session与cookie有关，根据不同的cookie服务器对session的判断也不同
这里提供一份flask的源码解析博客
其中指出flask的会话管理完全依赖cookie执行，服务器本身不保存相关数据，放到cookie中交给客户端保存
当客户端提交cookie时，服务器从cookie中解析出session，完成会话。
这就是flask默认提供的session功能，如果需要更加安全地将session保存到服务器，则需要使用flask-session库