HTTP 協定是無狀态的。是以，若不借助其他手段，遠端的伺服器就無法知道以前和用戶端做了哪些通信。Cookie 就是「其他手段」之一。 Cookie 一個典型的應用場景，就是用于記錄使用者在網站上的登入狀态。
使用者登入成功後，伺服器下發一個（通常是加密了的）Cookie 檔案。
用戶端（通常是網頁浏覽器）将收到的 Cookie 檔案儲存起來。
下次用戶端與伺服器連接配接時，将 Cookie 檔案發送給伺服器，由伺服器校驗其含義，恢複登入狀态（進而避免再次登入）。
當浏覽器作為用戶端與遠端伺服器連接配接時，遠端伺服器會根據需要，産生一個 SessionID，并附在 Cookie 中發給浏覽器。接下來的時間裡，隻要 Cookie 不過期，浏覽器與遠端伺服器的連接配接，都會使用這個 SessionID；而浏覽器會自動與伺服器協作，維護相應的 Cookie。
在 <code>requests</code> 中，也是這樣。我們可以建立一個 <code>requests.Session</code>，爾後在該 Session 中與遠端伺服器通信，其中産生的 Cookie，<code>requests</code> 會自動為我們維護好。
post 方法可以将一組使用者資料，以表單的形式發送到遠端伺服器。遠端伺服器接受後，依照表單内容做相應的動作。
調用 <code>requests</code> 的 POST 方法時，可以用 <code>data</code> 參數接收一個 Python 字典結構。<code>requests</code> 會自動将 Python 字典序列化為實際的表單内容。例如：
模拟登入的第一步，首先是要搞清楚我們用浏覽器登入時都發生了什麼。
而在 Chrome 的審查元素視窗中，我們可以看到送出給 <code>session</code> 接口的表單資訊。内裡包含
<code>commit</code>
<code>utf8</code>
<code>authenticity_token</code>
<code>login</code>
<code>password</code>
其中，<code>commit</code> 和 <code>utf8</code> 兩項是定值；<code>login</code> 和 <code>password</code> 分别是使用者名和密碼，這很好了解。唯獨 <code>authenticity_token</code> 是一長串無規律的字元，我們不清楚它是什麼。
POST 動作發生在與 <code>session</code> 接口互動之前，是以可能的資訊來源隻有 <code>login</code> 接口。我們打開 login 頁面的源碼，試着搜尋 <code>authenticity_token</code> 就不難發現有如下内容：
原來，所謂的 <code>authenticity_token</code> 是明白寫在 HTML 頁面裡的，隻不過用 <code>hidden</code> 模式隐藏起來了。為此，我們隻需要使用 Python 的正則庫解析一下，就好了。
1. 首先，我們準備好了和 Chrome 一緻的 HTTP 請求頭部資訊。具體來說，其中的 <code>User-Agent</code> 是比較重要的。
2. 仿照浏覽器與伺服器的通信，我們建立了一個 <code>requests.Session</code>。
3. 我們用 GET 方法打開登入頁面，并用正則庫解析到 <code>authenticity_token</code>。
4. 将所需的資料，整備成一個 Python 字典login_data
5. 最後，用 POST 方法，将表單送出到 <code>session</code> 接口。
6. 最終的結果經由 <code>302</code> 跳轉，打開了（<code>200</code>）GitHub 首頁.