webview HttpClient 怎麼保持會話session統一

 

cookies session均爲key---value的形式展現，

 1.    session是存儲在服務端，並有一塊區域控件存儲用戶信息，主要是爲了判斷該用戶是否登陸，在客戶端採用httpClient/HttpUrlConnection進行登陸請求的時候，傳過去的username=「ccc」 服務端中的session進行判斷是否存在改sessionId，以及value，不存在表明改用戶未曾登陸，服務器會自動生成惟一的sessionId其爲key,傳過來的ccc則爲value，key="sessionId" value=「ccc」,成功請求後下次進行http請求的時候請求頭會帶上這個sessionId進行跟服務端的session存儲區域進行判斷，是否登陸過，登陸過則返回成功，未登陸則重新分配。判斷相似map集合，經過map.get(sessionId)是否等於ccc。

   

2.     問題：httpClient中的cookie管理看什麼？

3.     CookieManager 是管理webview的，session是存儲在cookies中，httpclient登陸到服務器的時候，從http的cookie中取出sessionId放入到webview中（同步cookie），webview訪問業務的時候，因爲sessionId一致，服務器會認爲該用戶已登陸。

 

Cooki的獲取:

1 1
2 2
3 
4 CookieManager cm = CookieManager.getInstance();
5 String Cookiestr = cm.getCookie(url);

 

Cookie的同步:

1 Cookie的同步:
2 
3 
4 CookieSyncManager.createInstance(this);
5 
6 
7 CookieSyncManager.getInstance().sync();

 

清除Cookie:

1 清除Cookie:
2 
3      CookieManager.getInstance().removeSessionCookie();
4    或：
5 CookieManager.getInstance().removeAllCookies();

 

只要容許js就不能同步成功。緣由多是由於容許js就能經過ajax跨域獲取數據。可能處於安全考慮因此被禁止

 

httpclient與webview須要進行cookie 共享，由於若是不共享，那麼假設你在httpclient進行了登陸，而後用webview裏打開那些login以後才能看的page

 

1.  1 - DefaultHttpClient httpclient=....;
    2 - String toUrl="https://cap.cityu.edu.hk/studentlan/details.aspx.....";
    3 -
    4 - List<Cookie> cookies = httpclient.getCookieStore().getCookies();
    5 -
    6 - if (! cookies.isEmpty()){
    7 -     CookieSyncManager.createInstance(this);
    8 -     CookieManager cookieManager = CookieManager.getInstance();
    9 -         //sync all the cookies in the httpclient with the webview by generating cookie string
   10 -     for (Cookie cookie : cookies){
   11 -         String cookieString = cookie.getName() + "=" + cookie.getValue() + "; domain=" + cookie.getDomain();
   12 -         cookieManager.setCookie(toUrl, cookieString);
   13 -         CookieSyncManager.getInstance().sync();
   14 -     }
   15 - }

    

1 SharedPreferences spf = getSharedPreferences("Cookie", Context.MODE_PRIVATE);
2         CookieSyncManager.createInstance(this);
3         CookieManager cookieManager = CookieManager.getInstance();
4         String cookieString = spf.getString("cookieString", "");
5         cookieManager.setCookie(url, cookieString);
6         CookieSyncManager.getInstance().sync();
7 
8         webview.loadUrl(url);

 

 1   public static void addLoginCookie() {
 2         //登陸成功後 從新設置webviewcookie信息 用來保持session一致...................start
 3         CookieSyncManager.createInstance(App.getInstance().getApplicationContext());
 4         CookieManager cookieManager = CookieManager.getInstance();
 5 
 6         List<Cookie> cookies = App.getPersistentCookiesList();
 7         for (int i = 0; i < cookies.size(); i++) {
 8             Cookie cookie = cookies.get(i);
 9             String cookieString = cookie.getName() + "=" + cookie.getValue() + "; domain=" + cookie.getDomain();
10             cookieManager.setCookie(URLSet.cookiedomain, cookieString);
11         }
12 
13         CookieSyncManager.getInstance().sync();
14         //..................................................................end
15     }

 

 

參考連接 http://www.cnblogs.com/sharpxiajun/p/3395607.html

1.1 session的概念

 

          在計算機專業術語裏：session是指一個終端用戶與交互系統進行通訊的時間間隔， 一般指從註冊入系統到註銷系統之間所通過的時間以及若是須要的話，可能還有必定操做空間。

 

          具體到web應用裏的session，你們都作過web開發，這裏我就先不提出web裏session的定義，先和大夥講下和session相關的技術背景。

 

          早期的web應用或者說早期的網站都是一種處理靜態資源的網站，功能主要是查看文檔，看看圖片，而如今的web應用和早期的差異已經很大，互聯網的網站更準確的定義應該是互聯網軟件即網站就是軟件，網站所表明的軟件和早期軟件的定義是不同的，早期的軟件都是在單機環境下運行，而互聯網的普及讓軟件和網絡技術融合在一塊兒，這就要求網站所表明的軟件應該要有一個對事務處理的記憶功能，事務處理的記憶功能就是咱們常說的要有狀態。而實現web應用技術的核心http協議是一個無狀態的協議，http這種設計也許是歷史遺留問題，也許無狀態的http是最簡單也是最有效的通信方式，可是當網站成爲軟件後，狀態的保持就是一個很重要的功能。

所以在web應用開發裏就出現了保持http連接狀態的技術：一個是cookie技術，另外一種是session技術。

 

           cookie技術是客戶端的解決方案（固然隨着html5的出現，比cookie更爲強勁和安全的技術出現了，可是鑑於html5的普及度不夠，就不作本文討論的內容了），Cookie就是由服務器發給客戶端的特殊信息，而這些信息以文本文件的方式存放在客戶端，而後客戶端每次向服務器發送請求的時候都會帶上這些特殊的信息。讓咱們說得更具體一些： 當用戶使用瀏覽器訪問一個支持Cookie的網站的時候，用戶會提供包括用戶名在內的我的信息而且提交至服務器；接着，服務器在向客戶端回傳相應的超文本的同時也會發回這些我的信息，固然這些信息並非存放在HTTP響應體（Response Body）中的，而是存放於HTTP響應頭（Response Header）；當客戶端瀏覽器接收到來自服務器的響應以後，瀏覽器會將這些信息存放在一個統一的位置，對於Windows操做系統而言，咱們能夠從： [系統盤]:\Documents and Settings\[用戶名]\Cookies目錄中找到存儲的Cookie； 自此，客戶端再向服務器發送請求的時候，都會把相應的Cookie再次發回至服務器。而此次，Cookie信息則存放在HTTP請求頭（Request Header）了。有了Cookie這樣的技術實現， 服務器在接收到來自客戶端瀏覽器的請求以後，就可以經過分析存放於請求頭的Cookie獲得客戶端特有的信息，從而動態生成與該客戶端相對應的內容。一般，咱們能夠從不少網站的登陸界面中看到「請記住我」這樣的選項，若是你勾選了它以後再登陸，那麼在下一次訪問該網站的時候就不須要進行重複而繁瑣的登陸動做了， 而這個功能就是經過Cookie實現的。

 

          session技術則是服務端的解決方案，它是經過服務器來保持狀態的。因爲Session這個詞彙包含的語義不少，所以須要在這裏明確一下 Session的含義。首先，咱們一般都會把Session翻譯成會話，所以咱們能夠把 客戶端瀏覽器與服務器之間一系列交互的動做稱爲一個 Session。從這個語義出發，咱們會提到Session持續的時間，會提到在Session過程當中進行了什麼操做等等；其次 ，Session指的是服務器端爲客戶端所開闢的存儲空間，在其中保存的信息就是用於保持狀態。從這個語義出發，咱們則會提到往Session中存放什麼內容，如何根據鍵值從 Session中獲取匹配的內容等。要使用Session，第一步固然是建立Session了。那麼Session在什麼時候建立呢？固然仍是在 服務器端程序運行的過程當中建立的，不一樣語言實現的應用程序有不一樣建立Session的方法，而在Java中是經過調用HttpServletRequest的getSession方法（使用true做爲參數）建立的。 在建立了Session的同時，服務器會爲該Session生成惟一的Session id，而這個Session id在隨後的請求中會被用來從新得到已經建立的Session；在Session被建立以後，就能夠調用Session相關的方法往Session中增長內容了，而這些內容只會保存在服務器中，發到客戶端的只有Session id；當客戶端再次發送請求的時候，會將這個Session id帶上，服務器接受到請求以後就會依據Session id找到相應的Session，從而再次使用之。正式這樣一個過程，用戶的狀態也就得以保持了。

 

          由此咱們能夠得出， session是解決http協議無狀態問題的服務端解決方案，它能讓客戶端和服務端一系列交互動做變成一個完整的事務，能使網站變成一個真正意義上的軟件。

 

1.2 cookie與session的關係

          cookie和session的方案雖然分別屬於客戶端和服務端，可是服務端的session的實現對客戶端的cookie有依賴關係的，上面我講到 服務端執行session機制時候會生成session的id值，這個id值會發送給客戶端，客戶端每次請求都會把這個id值放到http請求的頭部發送給服務端，而這個id值在客戶端會保存下來，保存的容器就是cookie，所以當咱們徹底禁掉瀏覽器的cookie的時候，服務端的session也會不能正常使用（注意：有些資料說ASP解決這個問題，當瀏覽器的cookie被禁掉，服務端的session任然能夠正常使用，ASP我沒試驗過，可是對於網絡上不少用php和jsp編寫的網站，我發現禁掉cookie，網站的session都沒法正常的訪問）

 

1.3 session實現的原理

          java的web容器都實現了session機制，實現的邏輯思想都是一致的，可是具體方案可能會存在必定差別，這裏我以tomcat容器爲例，探討下session實現的機制。

下圖是tomcat源碼裏session實現：

 

 

          實現包的路徑是：org.apache.catalina.session，tomcat對外提供session調用的接口不在這個實現包裏，對外接口是在包javax.servlet.http下的HttpSession，而實現包裏的StandardSession是tomcat提供的標準實現，固然對外tomcat不但願用戶直接操做StandardSession，而是提供了一個StandardSessionFacade類，tomcat容器裏具體操做session的組件是servlet，而servlet操做session是經過StandardSessionFacade進行的，這樣就能夠防止程序員直接操做StandardSession所帶來的安全問題。(StandardSessionFacade使用了設計模式裏的Fa?ade（外觀）模式，外觀模式能讓不一樣邏輯層的組件進行解耦)。

 

實現類裏有Manager的類是用來管理session的工具類，它負責建立和銷燬session對象，其中ManagerBase是全部session管理工具類的基類，它是一個抽象類，全部具體實現session管理功能的類都要繼承這個類，該類有一個受保護的方法，該方法就是建立sessionId值的方法（tomcat的session的id值生成的機制是一個隨機數加時間加上jvm的id值，jvm的id值會根據服務器的硬件信息計算得來，所以不一樣jvm的id值都是惟一的），StandardManager類是tomcat容器裏默認的session管理實現類，它會將session的信息存儲到web容器所在服務器的內存裏。PersistentManagerBase也是繼承ManagerBase類，它是全部持久化存儲session信息的基類，PersistentManager繼承了PersistentManagerBase，可是這個類只是多了一個靜態變量和一個getName方法，目前看來意義不大，對於持久化存儲session，tomcat還提供了StoreBase的抽象類，它是全部持久化存儲session的基類，另外tomcat還給出了文件存儲FileStore和數據存儲JDBCStore兩個實現。

 

1.4 在實際運用中session所帶來的問題

           由上面所描述的session實現機制，咱們會發現，爲了彌補http協議的無狀態的特色，服務端會佔用必定的內存和cpu用來存儲和處理session計算的開銷，這也就是tomcat這個的web容器的併發鏈接那麼低（tomcat官方文檔裏默認的鏈接數是200）緣由之一。所以不少java語言編寫的網站，在生產環境裏web容器以前會加一個靜態資源服務器，例如：apache服務器或nginx服務器，靜態資源服務器沒有解決http無狀態問題的功能，所以部署靜態資源的服務器也就不會讓出內存或cpu計算資源專門去處理像session這樣的功能，這些內存和cpu資源能夠更有效的處理每一個http請求，所以靜態資源服務器的併發鏈接數更高，因此咱們可讓那些沒有狀態保持要求的請求直接在靜態服務器裏處理，而要進行狀態保持的請求則在java的web容器裏進行處理，這樣能更好的提高網站的效率。

 

          當下的互聯網網站爲了提升網站安全性和併發量，服務端的部署的服務器的數量每每是大於或等於兩臺，多臺服務器對外提供的服務是等價的，可是不一樣的服務器上面確定會有不一樣的web容器，由上面的講述咱們知道session的實現機制都是web容器裏內部機制，這就致使一個web容器裏所生成的session的id值是不一樣的，所以當一個請求到了A服務器，瀏覽器獲得響應後，客戶端存下的是A服務器上所生成的session的id，當在另外一個請求分發到了B服務器，B服務器上的web容器是不能識別這個session的id值，更不會有這個sessionID所對應記錄下來的信息，這個時候就須要兩個不一樣web容器之間進行session的同步。Tomcat容器有一個官方的解決方案就是使用apache+tomcat+mod_jk方案，當一個web容器裏session的信息發生變化後，該web容器會向另外一個web容器進行廣播，另外一個web收到廣播後將session信息同步到本身的容器裏，這個過程是十分消耗系統資源，當訪問量增長會嚴重影響到網站的效率和穩定性。

 

              我如今所作的網站裏有一個解決方案，當用戶請求網站的時候會先將請求發送給硬件的負載均衡設備，該設備能夠截獲客戶端發送過來的session的id值，而後咱們根據這個id值找到產生這個session的服務器，將請求直接發送給這臺服務器。這種解決方案看起來解決了session共享問題，其實結果是將集羣系統最終變回了單點系統，若是處理請求的web容器掛掉了，那麼用戶的相關會話操做也就廢掉了。此外，這種作法也干擾了負載均衡服務器的負載均衡的計算，讓請求的分發並非公平的。

 

　　通常大型互聯公司的網站都是有一個個獨立的頻道所組成的，例如咱們經常使用的百度，會有百度搜索，百度音樂，百度百科等等，我相信他們不會把這些不一樣頻道都給一個開發團隊完成，應該每一個頻道都是一個獨立開發團隊，由於每一個頻道的應用的都是獨立的web應用，那麼就存在一個跨站點的session同步的問題，跨站點的登陸可使用單點登陸的（SSO）的解決方案，可是無論什麼解決方案，跨站點的session共享任然是逃避不了的問題。

 

1.5 解決session相關問題的技術方案

由上所述，session一共有兩個問題須要解決：

1) session的存儲應該獨立於web容器，也要獨立於部署web容器的服務器；

2）如何進行高效的session同步。

 

在講到解決這些問題以前，咱們首先要考慮下session如何存儲纔是高效，是存在內存、文件仍是數據庫了？文件和數據庫的存儲方式都是將session的數據固化到硬盤上，操做硬盤的方式就是IO，IO操做的效率是遠遠低於操做內存的數據，所以文件和數據庫存儲方式是不可取的，因此將session數據存儲到內存是最佳的選擇。所以最好的解決方案就是使用分佈式緩存技術，例如：memcached和redis，將session信息的存儲獨立出來也是解決session同步問題的方法。

Tomcat的session同步也有使用memcache的解決方案，你們能夠參加下面的文章：

 

　 http://blog.sina.com.cn/s/blog_5376c71901017bqx.html

可是該方案只是解決了同步問題，session機制任然和web容器緊耦合，咱們須要一個高效、可擴展的解決方案，那麼咱們就應該不是簡單的把session獨立出來存儲而是設計一個徹底獨立的session機制，它既能給每一個web應用提供session的功能又能夠實現session同步，下面是一篇用zookeeper實現的分佈式session方案：

http://blog.sina.com.cn/s/blog_5376c71901017bqx.html

 

本身理解：

 

     客戶端首次訪問服務器的時候，http請求頭是空，服務器檢測並響應，若是是空則返回相應的session和對應的惟一sessionId,由於session是

客戶端根據http協議（無狀態鏈接）經過session和cookies自動設置，下次客戶端再進行http請求的時候，請求頭中傳入cookies，服務器自動獲取並校驗，若是是單純的瀏覽器，在校驗sessionId與服務器設置的超時時間相比，若是超時直接拉取登陸，未超時且一致則跳入相應的界面獲取相關信息。

 

由於http是無狀態協議，而cookie的做用就是爲了解決Http協議無狀態的缺陷。

session機制則是客戶端與服務器之間保持狀態的解決方案

 

 

參考連接： http://blog.csdn.net/axin66ok/article/details/6175522

 

1.cookie 是一種發送到客戶瀏覽器的文本串句柄，並保存在客戶機硬盤上(設置了有效期)，能夠用來在某個WEB站點會話間持久的保持數據。

 

2.session其實指的就是訪問者從到達某個特定主頁到離開爲止的那段時間。 Session實際上是利用Cookie進行信息處理的，當用戶首先進行了請求後，服務端就在用戶瀏覽器上建立了一個Cookie，當這個Session結束時，其實就是意味着這個Cookie就過時了。

注：爲這個用戶建立的Cookie的名稱是aspsessionid。這個Cookie的惟一目的就是爲每個用戶提供不一樣的身份認證。

 

3.cookie和session的共同之處在於：cookie和session都是用來跟蹤瀏覽器用戶身份的會話方式。

 

4.cookie 和session的區別是：cookie數據保存在客戶端，session數據保存在服務器端。

  簡單的說，當你登陸一個網站的時候:

 

·         若是web服務器端使用的是session，那麼全部的數據都保存在服務器上，客戶端每次請求服務器的時候會發送當前會話的sessionid，服務器根據當前sessionid判斷相應的用戶數據標誌，以肯定用戶是否登陸或具備某種權限。因爲數據是存儲在服務器上面，因此你不能僞造，可是若是你可以獲取某個登陸用戶的 sessionid，用特殊的瀏覽器僞造該用戶的請求也是可以成功的。sessionid是服務器和客戶端連接時候隨機分配的，通常來講是不會有重複，但若是有大量的併發請求，也不是沒有重複的可能性.

 

·         若是瀏覽器使用的是cookie，那麼全部的數據都保存在瀏覽器端，好比你登陸之後，服務器設置了cookie用戶名，那麼當你再次請求服務器的時候，瀏覽器會將用戶名一塊發送給服務器，這些變量有必定的特殊標記。服務器會解釋爲cookie變量，因此只要不關閉瀏覽器，那麼cookie變量一直是有效的，因此可以保證長時間不掉線。若是你可以截獲某個用戶的 cookie變量，而後僞造一個數據包發送過去，那麼服務器仍是認爲你是合法的。因此，使用 cookie被攻擊的可能性比較大。若是設置了的有效時間，那麼它會將 cookie保存在客戶端的硬盤上，下次再訪問該網站的時候，瀏覽器先檢查有沒有 cookie，若是有的話，就讀取該 cookie，而後發送給服務器。若是你在機器上面保存了某個論壇 cookie，有效期是一年，若是有人入侵你的機器，將你的  cookie拷走，而後放在他的瀏覽器的目錄下面，那麼他登陸該網站的時候就是用你的的身份登陸的。因此 cookie是能夠僞造的。固然，僞造的時候須要主意，直接copy    cookie文件到 cookie目錄，瀏覽器是不認的，他有一個index.dat文件，存儲了 cookie文件的創建時間，以及是否有修改，因此你必須先要有該網站的 cookie文件，而且要從保證時間上騙過瀏覽器

 

5.兩個均可以用來存私密的東西，一樣也都有有效期的說法,區別在於session是放在服務器上的，過時與否取決於服務期的設定，cookie是存在客戶端的，過去與否能夠在cookie生成的時候設置進去。

(1)cookie數據存放在客戶的瀏覽器上，session數據放在服務器上
(2)cookie不是很安全，別人能夠分析存放在本地的COOKIE並進行COOKIE欺騙,若是主要考慮到安全應當使用session
(3)session會在必定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能，若是主要考慮到減輕服務器性能方面，應當使用COOKIE
(4)單個cookie在客戶端的限制是3K，就是說一個站點在客戶端存放的COOKIE不能3K。

(5)因此：將登錄信息等重要信息存放爲SESSION;其餘信息若是須要保留，能夠放在COOKIE中