Ⅰ android 連接Http的時候有session嗎
當Android應用程序訪問WEB伺服器的時候，我們為了與伺服器保持同一會話，也就是說當前登錄用戶與伺服器的交互是在同一個SessionId下。當我們登錄成功的時候，可以通過HTTP請求獲取到Cookie信息，其中包括會話的SessionId，同時也可以自己將SessionId放入Json中返回。Session我們可以用一個靜態變數來存放，每次向伺服器發送請求的時候將SessionId帶過去，伺服器會自動檢驗這個SessionId有沒有失效。DefaultHttpClient httpclient = new DefaultHttpClient();HttpPost httpPost = new HttpPost(訪問地址);httpPost.setHeader("Cookie", "JSESSIONID=" + 我們在靜態變數里存放的SessionId);HttpResponse httpResponse = httpclient.execute(httpPost);這樣就可以將SessionId帶過去了。
Ⅱ 求助，關於Android無法讀取session的問題
你好，很高興為你解答
可能的情況是：android與WEB伺服器交互時，沒有在同一個會話Session中通信
，因為android手機端在訪問web伺服器時，沒有給http請求頭部設置sessionID，而使用web瀏覽器作為客戶端訪問伺服器時，在客戶端每
次發起請求的時候，都會將交互中的sessionID：JSESSIONID設置在Cookie頭中攜帶過去，伺服器根據這個sessionID獲取對應
的Session,而不是重新創建一個新Session(除了這個Session失效)
希望能幫到你，謝謝
Ⅲ Android登陸後如何判定是否登錄 並且在已經登錄的時候如何獲取用戶信息
給你詳細講一下。 比如系統有個登陸頁面(login.jsp)： name:_________ password:____________ (登陸按鈕） 你按下登陸按鈕，就根據name和password去資料庫裡面查，如果判斷有此用戶並且密碼正確，就設置一個session的鍵對應的值，鍵名字自己取，統一即可，比如"userInfo"，代碼就是servlet的doPost裡面 HttpSession session = request.getSession(); Hashtable userInfo = new Hashtable(); userInfo.setAttribute("userName", request.getParameter("userName"); userInfo.setAttribute("passWords", Util.toSecret( request.getParameter("passWords)); //密碼最好加密 session.setAttribute("userInfo", userInfo); session是在一定時期（超時時間內）一直存在的，這段時間內你可以隨時判斷用戶是否合法，否則就退回登陸頁面。 在任何除了登陸頁面以外的頁面訪問，只需判斷有沒有這個鍵值，沒就到登陸頁面，否則進正常頁面。（最好寫在servlet中，讓servlet當頁面控制器）代碼如下： if ( session.getAttribute("userInfo")==null ) { response.sendRedirect(request.getServletContext.getPath() + "/login.jsp"); } else { request.getRequestDispatcher("/正常頁面.jsp").forward(request,response); }
Ⅳ Android網路請求知識（三）授權，TCP/IP，HTTPS建立過程
由身份或持有的令牌確認享有的許可權，登錄過程實質上的目的也是為了確認許可權。
Cookie是客戶端給伺服器用的，setCookie是伺服器給客戶端用的。cookie由伺服器處理，客戶端負責存儲
客戶端發送cookie：賬戶和密碼
服務端收到後確認登錄setCookie：sessionID=1，記下sessionID
客戶端收到sessionID後記錄，以後請求服務端帶上對比記錄下sessionID，說明已經登錄
會話管理：登錄狀態，購物車
個性化：用戶偏好，主題
Tracking：分析用戶行為
XXS：跨腳本攻擊，及使用JavaScript拿到瀏覽器的cookie之後，發送到自己的網站，以這種方式來盜用用戶Cookie。Server在發送Cookie時，敏感的Cookie加上HttpOnly，這樣Cookie只能用於http請求，不能被JavaScript調用
XSRF:跨站請求偽造。Referer 從哪個網站跳轉過來
兩種方式：Basic和Bearer
首先第三方網站向授權網站申請第三方授權合作，拿到授權方頒發的client_id和client_secret（一般都是appid+appkey的方式）。
在這就過程中申請的client_secret是伺服器持有的，安全起見不能給客戶端，用服務端去和授權方獲取用戶信息，再傳給客戶端，包括④，⑤的請求過程也是需要加密的。這才是標準的授權過程。
有了access_token之後，就可以向授權方發送請求來獲取用戶信息
步驟分析就是上面的內容，這里把第4,6,8請求的參數分析一下
第④步參數：
response_type：指授權類型，必選，這里填固定值『code』
client_id：指客戶端id，必選，這里填在平台報備時獲取的appid
redirect_uri：指重定向URI，可選
scope：指申請的許可權范圍，可選
state：指客戶端當前狀態，可選，若填了，則認證伺服器會原樣返回該值
第⑥步參數：
grant_type：指使用哪種授權模式，必選，這里填固定值『authorization_code』
code：指從第⑤步獲取的code，必選
redirect_uri：指重定向URI，必選，這個值需要和第④步中的redirect_uri保持一致
client_id：指客戶端id，必選，這里填在平台報備時獲取的appid
client_secret：指客戶端密鑰，必選，這里填在平台報備時獲取的appkey
第⑧步參數：
access_token：指訪問令牌，必選，這里填第⑦步獲取的access_token
token_type：指令牌類型，必選，大小寫不敏感，bearer類型 / mac類型
expires_in：指過期時間，單位秒，當其他地方已設置過期時間，此處可省略該參數
refresh_token：指更新令牌，可選，用即將過期token換取新token
scope：指許可權范圍，可選，第④步中若已申請過某許可權，此處可省略該參數
我們在上面的第八步中會有refresh_token的參數，這個在實際操作中也比較常見
有時候我們在自己的項目中，將登陸和授權設計成類似OAuth2的過程，不過去掉Authorization code。登陸成功返回access_token，然後客戶端再請求時，帶上access_token。
我們常常會說到TCP/IP，那到底是什麼呢。這就需要講到網路分層模型。TCP在傳輸層，IP在網路層。那為什麼需要分層？因為網路不穩定，導致需要重傳的問題。為了提高傳輸效率我們就需要分塊，在傳輸層中就會進行分塊。TCP還有兩個重要的內容就是三次握手，四次分手。
HTTPS 協議是由 HTTP 加上TLS/SSL協議構建的可進行加密傳輸、身份認證的網路協議，主要通過數字證書、加密演算法、非對稱密鑰等技術完成互聯網數據傳輸加密，實現互聯網傳輸安全保護
1.客戶端通過發送Client Hello報文開始SSL通信。報文中包含客戶端支持的SSL的指定版本、加密組件列表（所使用的加密演算法及密鑰長度），客戶端隨機數，hash演算法。
2.伺服器可進行SSL通信時，會以Server Hello報文作為應答。和客戶端一樣，在報文中包含SSL版本以及加密組件，服務端隨機數。伺服器的加密組件內容是從接收到客戶端加密組件內篩選出來的。
3.之後伺服器發送Certificate報文。報文中包含公開密鑰證書。一般實際有三層證書嵌套，其實像下面圖二直接用根證書機構簽名也是可以的，但是一般根證書機構比較忙，需要類似中介的證書機構來幫助。
4.最後伺服器發送Server Hello Done報文通知客戶端，最初階段的SSL握手協商部分結束。
5.SSL第一次握手結束後，客戶端以Client Key Exchange報文作為回應。報文中包含通信加密中使用的一種被稱為Pre-master secret的隨機密碼串。該報文已用步驟3中的公開密鑰進行加密。
6.接著客戶端繼續發送Change Cipher Spec報文。該報文會提示伺服器，在此報文之後的通信會採用Pre-master secret密鑰加密。
7.客戶端發送Finished報文。該報文包含連接至今全部報文的整體校驗值。這次握手協商是否能夠成功，要以伺服器是否能夠正確解密報文作為判定標准。
8.伺服器同樣發送Change Cipher Spec報文。
9.伺服器同樣發送Finished報文。
10.伺服器和客戶端的Finished報文交換完畢之後，SSL連接就算建立完成。當然，通信會受到SSL的保護。從此處開始進行應用層協議的通信，即發送HTTP響應。
11.應用層協議通信，即發送HTTP響應。
12.最後由客戶端斷開連接。斷開連接時，發送close_notify報文。這步之後再發送TCP FIN報文來關閉與TCP的通信。
利用客戶端隨機數，服務端隨機數，per-master secret隨機數生成master secret，再生成客戶端加密密鑰，服務端加密密鑰，客戶端MAC secert，服務端MAC secert。MAC secert用於做報文摘要，這樣能夠查知報文是否遭到篡改，從而保護報文的完整性。
Android網路請求知識（一）HTTP基礎概念
Android網路請求知識（二）對稱和非對稱加密、數字簽名，Hash，Base64編碼
Android網路請求知識（三）授權，TCP/IP，HTTPS建立過程
Ⅳ 安卓與伺服器之間的session機制一般是怎麼實現的
Cookie和Session都為了用來保存狀態信息，都是保存客戶端狀態的機制，它們都是為了解決HTTP無狀態的問題而所做的努力。
Session可以用Cookie來實現，也可以用URL回寫的機制來實現。
Cookie和Session有以下明顯的不同點：
1）Cookie將狀態保存在客戶端，Session將狀態保存在伺服器端；
2）Cookies是伺服器在本地機器上存儲的小段文本並隨每一個請求發送至同一個伺服器。網路伺服器用HTTP頭向客戶端發送cookies，在客戶終端，瀏覽器解析這些cookies並將它們保存為一個本地文件，它會自動將同一伺服器的任何請求縛上這些cookies。
3）Session是針對每一個用戶的，變數的值保存在伺服器上，用一個sessionID來區分是不同用戶session變數,這個值是通過用戶的瀏覽器在訪問的時候返回給伺服器，當客戶禁用cookie時，這個值也可能設置為由get來返回給伺服器；
4）就安全性來說：當你訪問一個使用session 的站點，同時在自己機器上建立一個cookie，建議在伺服器端的SESSION機制更安全些.因為它不會任意讀取客戶存儲的信息。