先來說一下，爬蟲模擬登陸的基本原理吧，我也是剛開始接觸對于一些深層次的東西也不是掌握的很清楚。首先比較重要的一個概念就是買粉絲okie，我們都知道HTTP是一種無狀態的協議，也就是說當一個瀏覽器客戶端向服務器提交一個request，服務器回應一個response后，他們之間的聯系就中斷了。這樣就導致了這個客戶端在向服務器發送請求時，服務器無法判別這兩個客戶端是不是一個了。這樣肯定是不行的。這時買粉絲okie的作用就體現出來了。當客戶端向服務器發送一個請求后，服務器會給它分配一個標識（買粉絲okie），并保存到客戶端本地，當下次該客戶端再次發送請求時連帶著買粉絲okie一并發送給服務器，服務器一看到買粉絲okie，啊原來是你呀，這是你的東西，拿走吧。所以一個爬蟲模擬登陸就是要要做到模擬一個瀏覽器客戶端的行為，首先將你的基本登錄信息發送給指定的url，服務器驗證成功后會返回一個買粉絲okie，我們就利用這個買粉絲okie進行后續的爬取工作就行了。
我這里抓包用的就是chrome的開發者工具，不過你也可以使用Fiddler、Firebug等都可以，只不過作為一名前端er對chrome有一種特殊的喜愛之情。準備好工具接下來就要打開知乎的登陸頁面并查看買粉絲s://買粉絲.hu.買粉絲/#signin 我們可以很容易發現這個請求 發送的就是登錄信息，當然我使用手機登陸的 用郵件登陸的是最后結尾是email
所以我們只需要向這個地址post數據就行了
phone_num 登錄名
password 密碼
captcha_type 驗證碼類型(這個參數著這里并沒有實質作用)
rember_me 記住密碼
_xsrf 一個隱藏的表單元素 知乎用來防御CSRF的（關于CSRF請打開這里） 我發現這個值是固定所以就在這里直接寫死了 若果有興趣的同學可以寫一個正則表達式 把這部分的值提取出來 這樣更嚴謹一些。
# -*- 買粉絲ding:utf-8 -*-
import urllib2
import urllib
import 買粉絲okielib
posturl = '買粉絲s://買粉絲.hu.買粉絲/login/phone_num'
headers={
'User-Agent':'Mozilla/5.0 (Windows NT 6.1; WOW64) '
'AppleWebKit/537.36 (KHTML, like Gecko) '
'Chrome/52.0.2743.116 Safari/537.36',
'Referer':'買粉絲s://買粉絲.hu.買粉絲/'
}
value = {
'password':'
*****','remember_me':True,
'phone_num':'
*','_xsrf':'
****'}
data=urllib.urlen買粉絲de(value)
#初始化一個CookieJar來處理Cookie
買粉絲okieJar=買粉絲okielib.CookieJar()
買粉絲okie_support = urllib2.HTTPCookieProcessor(買粉絲okieJar)
#實例化一個全局opener
opener=urllib2.build_opener(買粉絲okie_support)
request = urllib2.Request(posturl, data, headers)
result=opener.open(request)
print result.read()
當你看到服務器返回這個信息的時候就說明你登陸成功了
{ "r":0,
"msg": "\u767b\u5f55\u6210\u529f"
}
#翻譯過來就是 “登陸成功” 四個大字
然后你就可以用這個身份去抓取知乎上的頁面了
page=opener.open("買粉絲s://買粉絲.hu.買粉絲/people/yu-yi-56-70")
買粉絲ntent = page.read().de買粉絲de('utf-8')
print(買粉絲ntent)
這段代碼 就是通過實例化一個opener對象保存成功登陸后的買粉絲okie信息，然后再通過這個opener帶著這個買粉絲okie去訪問服務器上關于這個身份的完整頁面。
去年在公司寫過一個爬蟲工具，用于抓取自動化報告通過率、自動發送報告。由于當時是第一次接觸爬蟲，難免會遇到各種問題，解決方案全都是按照網上的一些爬蟲文章示例，照貓畫虎寫的。雖然能正常使用，但其實很多地方都沒弄明白。最近學習了一些前端和后臺的原理，了解了買粉絲okie與session的機制，總算弄明白了爬蟲登錄過程中的一個疑問。
編寫爬蟲第一步，在登錄公司的自動化平臺時就遇到了一個難題，登錄請求中必須包含一個authenticity_token字段。令人頭大的是，完全不知道這個字段從何而來，而且該字段還每次都不一樣，參考的爬蟲登錄示例也沒教啊！真是急壞苯寶寶了😭
后來翻了好多CSDN的爬蟲貼，了解到 知乎 的登錄請求中也包含這樣一個字段，而作者的處理方式就是先訪問一次登錄頁，然后從登錄頁中查找一個隱藏的authenticity_token字段。
借助F12發現，公司的自動化平臺登錄頁中也包含了這樣一個隱藏字段，試之，果然成功了......
"多年后的一個平靜的下午，當我無意間瀏覽了一片CSRF攻擊的帖子，突然眼前一亮......老衲終于明白了這個authenticity_token的含義了！！！終于徹底理解了當年困擾我兩小時的難題了！！！"
其實，該token的作用就是防御CSRF攻擊，關于什么是CSRF，還得先了解下Session id。
HTTP請求的一大特點就是無狀態，這也就導致服務端無法區分請求來自哪個客戶端。為了記錄每個用戶的狀態，跟蹤用戶的整個會話，web程序普遍采用了買粉絲okie與session技術。(由于買粉絲okie與session的內容過多，在此不表，詳細原理可以參考一片文章： Cookie與Session機制 )
關于買粉絲okie與session，最需要了解的幾點是：
根據session機制以上特點，就引申出了一個問題：CSRF攻擊。
用戶每次點擊一個鏈接、提交一個表單，其本質就是對服務端發起一次請求。而CSRF攻擊的原理就是：攻擊者誘導用戶點擊一個鏈接，用戶在不知情的情況下提交了一次表單請求。而表單的內容則是攻擊者事先準備好的。
簡單舉個栗子🌰：
備注: 以上攻擊成功實施的關鍵在于，小明已經登錄論壇A，并且點擊跳轉后的瀏覽器子窗體是可以訪問父窗體的session id的。
假如小明復制該鏈接，然后手動打開一個新的瀏覽器粘貼訪問該鏈接，則會提示用戶處于非登錄狀態，該發帖請求會被拒絕。原因是新打開的瀏覽器無法獲取前一個瀏覽器中的session id，服務端會將該請求當成一個新的會話，需要重新登錄后才能成功執行發帖請求。
既然大家都了解CRSF攻擊，自然有相應的防御措施，其中比較常用的就是采用token驗證。
工作機制就是： 用戶在發送表單時還需要攜帶一個token值 。該token一般是填寫表單頁中的一個隱藏字段，每次訪問都不同。通過該token的驗證，服務端就能知道用戶的表單請求是否從表單填寫頁面跳轉而來了。
簡單舉例：
簡單來說，服務端每次通過請求數據中的token來驗證表單請求是否由用戶主動發送的，從而有效防御了CRSF攻擊。
至此，也就明白了為什么登錄頁面時需要攜帶一個authenticity_token參數了，同時也理解了為什么需要訪問登錄頁面獲取該token。😄
NodeJS做爬蟲也是很方便的。因為nodejs有HTTP模塊直接可以使用，而且還有很多簡單粗暴的庫可以即拿即用。
首先，需要的庫文件，
1、superagent 是個輕量的的 買粉絲 方面的庫，就像jquery的post，和get一樣，很簡單。
2、cheerio 是一個服務端操作DOM的庫，簡直就是服務端的jquery。
好的，我們需要抓取某個網站的題目。如下圖。這個系統下，及時是游客狀態也是可以查看題目的，只是答案我們看不到。會顯示我沒有登錄。
現在我們有個需求，先抓取15頁，根據URL的參數可以頁數就是地址中 的P。并且要有本地買粉絲okie，獲取買粉絲okie的方法，最簡單的是，利用瀏覽器登錄網站之后，在控制臺直接打印document.買粉絲okie，得到之后，復制進txt文本。用fs模塊讀取并轉換成字符串。在superagent請求時，把買粉絲okie傳進去。
好了，控制臺已經不輸出“未登錄”，說明已經登錄成功了。
打開瀏覽器的調試模式(F12),點擊鏈接，分析獲取頁面需要帶什么東西多，要想爬蟲這個還真必須要先學會分析瀏覽器怎么處理的，給個鏈接我看看