首先,第三方受權怎麼作請百度。java
正文,請先看代碼sql
public class MyApplication extends Application { public static Context context;//登陸的用戶id public static String username;//登陸的用戶名 public static int userid;//登陸的用戶id public static boolean loginflag;//用戶的登陸狀態 @Override public void onCreate() { loginflag=false; context=this; checkLogin(); } public void checkLogin() { new Thread(){ @Override public void run() { super.run(); //本app本身的帳戶系統 //1.使用保存的登錄狀態(需保存用戶狀態和至少一個惟一性字段,如用戶id;可是明顯不安全) //2.請求服務器登錄(使用保存的用戶名和密碼) //藉助sns的受權登錄 //3.使用保存下來的Token驗證,無需發送給服務器了(最終也是不安全) //第3種狀況 參考各sns平臺的Token類的有效性判斷方法boolean isSessionValid() //發現: //保存Token都是有風險的,並且本地的數據又能夠僞造+Token類自己的判斷只依賴這種數據 //那麼就同 第1種 相似了 //4.每次都調出sns平臺的受權頁,如同第一次受權般 } }.start(); }
首先這有個假設,就是能夠人爲地對程序保留數據(如sqlite、sharedpreferences)進行更改。沒有root的安卓設備彷佛不能夠改,但已root的安卓設備應該能夠改。由於我沒有設備可測,可是使用AVD模擬器,發現能夠導入導出sharedpreferences的xml和使用adb進入sqlite,應該也能夠修改。而猜測AVD至關因而已root的安卓設備。安全
第1種狀況 明顯不安全在於,只修改用戶id就能夠登陸別人的帳號了;服務器
第2種狀況 我認爲是安全的;app
第3種狀況 我認爲不安全在於,一是修改expires_in能夠一直可以登陸該app,二是修改uid也許就能登陸別人的帳號。ide
詳細請見上面代碼註釋,只附下代碼ui
(sina微博的Token類)this
public boolean isSessionValid() { return !TextUtils.isEmpty(mAccessToken); }
qq的Token類也是相似的判斷。code
第4種狀況,原本我是以爲這樣子很麻煩,但彷佛沒有其餘方案,好比經過一個方法不用拉取受權頁就能向sns平臺調取上一次的Token,由於你保存這個Token在本地那就不安全,可是目前我沒有找到這個方法。sqlite
一點點安慰,看了下qq鬥地主和雷霆戰機 這兩款app對QQ自動登陸也是使用的方案4。
思考了下第4種的替代,就是贊成受權登錄後到本app服務器獲取用戶名和密碼保存,可是形成了密碼泄露,另外服務器也可能不直接存儲密碼,因此仍是別這麼用。