HTTP 協議是無狀態的。因此,若不借助其他手段,遠程的服務器就沒法知道之前和客戶端做了哪些通訊。Cookie 就是「其他手段」之1。 Cookie 1個典型的利用場景,就是用于記錄用戶在網站上的登錄狀態。
requests使用cookie
當閱讀器作為客戶端與遠端服務器連接時,遠端服務器會根據需要,產生1個 SessionID,并附在 Cookie 中發給閱讀器。接下來的時間里,只要 Cookie 不過期,閱讀器與遠端服務器的連接,都會使用這個 SessionID;而閱讀器會自動與服務器協作,保護相應的 Cookie。
在 requests
中,也是這樣。我們可以創建1個 requests.Session
,爾后在該 Session 中與遠端服務器通訊,其中產生的 Cookie,requests
會自動為我們保護好。
post 方法可以將1組用戶數據,以表單的情勢發送到遠端服務器。遠端服務器接受后,依照表單內容做相應的動作。
調用 requests
的 POST 方法時,可以用 data
參數接收1個 Python 字典結構。requests
會自動將 Python 字典序列化為實際的表單內容。例如:
摹擬登錄的第1步,首先是要弄清楚我們用閱讀器登錄時都產生了甚么。
GitHub 登錄頁面是 https://github.com/login。我們首先清空閱讀器 Cookie 記錄,然后用 Chrome 打開登錄頁面。填入 Username 和 Password 以后,我們打開 Tamper Chrome 和 Chrome 的元素審查工具(找到 Network 標簽頁),以后點登錄按鈕。
在 Tamper Chrome 中,我們發現:雖然登錄頁面是 https://github.com/login,但實際接收表單的是 https://github.com/session。若登錄成功,則跳轉到 https://github.com/ 首頁,返回狀態碼 200
。
而在 Chrome 的審查元素窗口中,我們可以看到提交給 session
接口的表單信息。內里包括
commit
utf8
authenticity_token
login
password
其中,commit
和 utf8
兩項是定值;login
和 password
分別是用戶名和密碼,這很好理解。惟獨 authenticity_token
是1長串無規律的字符,我們不清楚它是甚么。
POST 動作產生在與 session
接口交互之前,因此可能的信息來源只有 login
接口。我們打開 login 頁面的源碼,試著搜索 authenticity_token
就不難發現有以下內容:
原來,所謂的 authenticity_token
是明白寫在 HTML 頁面里的,只不過用 hidden
模式隱藏起來了。為此,我們只需要使用 Python 的正則庫解析1下,就行了。
1. 首先,我們準備好了和 Chrome 1致的 HTTP 要求頭部信息。具體來講,其中的 User-Agent
是比較重要的。
2. 仿照閱讀器與服務器的通訊,我們創建了1個 requests.Session
。
3. 我們用 GET 方法打開登錄頁面,并用正則庫解析到 authenticity_token
。
4. 將所需的數據,整備成1個 Python 字典login_data
5. 最后,用 POST 方法,將表單提交到 session
接口。
6. 終究的結果經過 302
跳轉,打開了(200
)GitHub 首頁.
上一篇 快速冪