做過Android的朋友可能會發現手機的app與服務器接口之間的數據交換是非常頻繁的，在Java-WEB中前臺界面與服務器之間有一個安全機制session，它的存在可以過濾掉很多非登陸狀態的請求，那如何才能保證普通的移動終端iOS或是android端的請求時合法有效的呢，下面我總結也嘗試了幾種方式，當然不管哪一種機制，都有其弊端，也不是絕對安全的，只能說比不進行任何處理要好的多。
1.請求頭裏帶用戶username和password，到服務器端做驗證，通過才繼續下邊業務邏輯。
有點：防止了服務器端api被隨意調用。
缺點：每次都交互用戶名和密碼，交互量大，且密碼明文傳輸不安全。
2.第一次請求，要求username和password，驗證通過，種cookie到客戶端，app保存cookie值。
每次請求帶上cookie。
點評：和pc上瀏覽器認證的原理一樣了。
以上兩點，只有註冊用戶，纔能有權訪問業務邏輯，而app有大量的不需要註冊數據api
3.制定一個token生成規則，按某些服務器端和客戶端都擁有的共同屬性生成一個隨機串，客戶端生成這個串，服務器收到請求也校驗這個串。
缺點：隨機串生成規則要保密。
比如:一個使用PHP框架的工程，框架每次交互都會有 module和action兩個參數做路由，這樣的話，我就可以用下邊這個規則來生成token
app要請求用戶列表，api是“index.do?module=user&action=list”
app生成token = md5sum ('user'.'2012-11-28'.'#$@%!'.list) = 880fed4ca2aabd20ae9a5dd774711de2;
實際發起請求爲 “index.php?module=user&action=list&token=880fed4ca2aabd20ae9a5dd774711de2”
服務器端接到請求用同樣方法計算token，當然你可以自己封裝一下Md5算法。
當然，上面的三種方法都是行之有效，但是被反編譯後，還是逃不過hack app的攻擊，還有一種方式就是類似瀏覽器與服務器的通信一樣，模擬出session。
4.
原因很簡單，就是因爲android手機端在訪問web服務器時，沒有給http請求頭部設置sessionID，而使用web瀏覽器作爲客戶端訪問服務器時，在客戶端每次發起請求的時候，都會將交互中的sessionID：JSESSIONID設置在Cookie頭中攜帶過去，服務器根據這個sessionID獲取對應的Session,而不是重新創建一個新Session(除了這個Session失效)。不過有很多android程序的請求，會直接用其他框架的請求方式像常見的volley等等。那樣處理起來就不方便了。
以java.NET.HttpURLConnection發起請求爲例：
獲取Cookie：
URL url = new URL(requrl);
HttpURLConnection con= (HttpURLConnection) url.openConnection();
// 取得sessionid.
String cookieval = con.getHeaderField("set-cookie");
String sessionid;
if(cookieval != null) {
sessionid = cookieval.substring(0, cookieval.indexOf(";"));
}
//sessionid值格式：JSESSIONID=AD5F5C9EEB16C71EC3725DBF209F6178，是鍵值對，不是單指值
發送設置cookie：
URL url = new URL(requrl);
HttpURLConnectioncon= (HttpURLConnection) url.openConnection();
if(sessionid != null) {
con.setRequestProperty("cookie", sessionid);
}
只要設置了sessionID，這樣web服務器在接受請求的時候就會自動搜索對應的session了，從而保證了在同一會話Session。