模擬登陸的背後

瀏覽器和服務器(session)之間的相互識別,是通過服務器端session的id來識別的,現在具體描述一個瀏覽器和服務器之間會話的過程:

1. 瀏覽器第一次向指定服務器發送請求;

2.服務器接收到請求創建一個session對象(會話),session對象具有一個唯一標識的屬性id;

3.服務器在給客戶端的響應報文中,以cookie的形式將sessionid返回給客戶端(tomcat和jetty服務器環境下,這個cookie的名稱爲jsessionid),客戶端接收到響應報文中響應頭內的cookie,將其存在瀏覽器(這個cookie在瀏覽器關閉時自動銷燬);

4. 第二次請求服務器時,服務器端返回的cookie被帶在了請求頭中,服務器端獲取到客戶端傳來的cookie值後和服務器上已存在的session匹配。如果匹配上了,則在匹配上的session基礎上完成後續操作,可以使用session中存儲的數據,以後的響應頭中不含sessionid。如果服務器端沒有能夠匹配的session,則創建一個新的session對象,執行過程3.


遇到的一些現象及其原理:

1.現象: 電腦短時間斷網,等網絡恢復後發現原來的登錄狀態任然存在。

原理:客戶端的網絡雖然斷了,但是瀏覽器沒有關閉cookie沒有銷燬仍然存在,等網絡恢復後,只要服務器端session還存在(maxInactiveInterval時間內),客戶端提供的cookie任然能夠和服務器端的session匹配,可以繼續進行斷網前的操作。

2.現象:清空了瀏覽器的cookie,發現瀏覽器沒有關閉,但是操作網頁時不能正常操作,跳到了登錄頁,顯示請重新登錄。

原理:此種情況是瀏覽器和服務器端session匹配的cookie丟失導致瀏覽器無法提供和服務器端匹配的key,導致登錄失效,不得不重新登錄,服務器端創建新的session對象。原有的session對象則在maxInactiveInterval時間結束後自動銷燬。同樣,客戶端如果長時間不向服務器端發送請求,登錄狀態也會失效,當請求間隔時間超過session的maxInactiveInterval,session自動銷燬,等客服端再向服務器端發送請求時就找不到能夠匹配的session,不得不重新創建session,原來的客戶端的cookie值也會被新返回的cookie值替換。

一些網頁禁止抓取:

可以在代碼中模擬客戶端欺騙服務器,具體做法是在請求頭中加入UserAgent(用戶代理)屬性及其值,值可以用瀏覽器的。

 



總結:決定服務暢通的關鍵是客戶端和服務器端都能夠提供相互匹配的標識,無論任意一方出現問題,服務都會出現問題。模擬登陸登陸狀態的保存,要點在於在第二(非第一次)次請求時將第一次響應頭中的cookie值設置到請求頭中,實現客戶端本次請求和上次會話的對接。


簡單瞄了下,這篇文章也是講模擬登陸的,還有代碼實現:

http://www.cnblogs.com/moon-mountain/archive/2012/02/11/2346922.html


發佈了48 篇原創文章 · 獲贊 3 · 訪問量 8萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章