先說下背景,項目包含一個管理系統(web)和門戶網站(web),還有一個手機APP(包括Android和IOS),三個系統共用一個后端,在后端使用shiro進行登錄認證和權限控制。好的,那么問題來了web和APP都可以用shiro認證嗎?兩者有什么區別?如果可以,解決方案是什么?看着大家焦急的小眼神,接下來挨個解決上面的問題。
web和APP可以用shiro統一登錄認證嗎?
可以。假如web和APP都使用密碼登錄的話,那沒的說肯定是可以的,因為對於shiro(在此不會介紹shiro詳細知識,只介紹本文章必要的)來說,不管是誰登錄,用什么登錄(用戶名密碼、驗證碼),只要通過subject.login(token)中的token告訴shiro,然后在自己定義的Realm里面給出自己的認證字段就可以了,好吧說的雲里霧里,看看代碼
// 在自己登錄的rest里面寫,比如UserRest里面的login方法中,user為傳遞過來的參數 Subject currentUser = SecurityUtils.getSubject(); UsernamePasswordToken token = new UsernamePasswordToken(user.getUserName(), user.getPassword()); // 開始進入shiro的認證流程 currentUser.login(token);
上面的代碼是開始使用shiro認證,調用subject.login(token)之后就交給shiro去認證了,接下來和我們相關的就是自定認證的Realm了,比如自定義UserRealm
protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken authcToken) throws AuthenticationException { //獲取基於用戶名和密碼的令牌 //實際上這個token是從UserResource面currentUser.login(token)傳過來的 //兩個token的引用都是一樣的 UsernamePasswordToken token = (UsernamePasswordToken)authcToken; System.out.println("驗證當前Subject時獲取到token為" + ReflectionToStringBuilder.toString(token, ToStringStyle.MULTI_LINE_STYLE)); // 從數據庫中獲取還用戶名對應的user User user = userService.getByPhoneNum(token.getUsername()); if(null != user){ AuthenticationInfo authcInfo = new SimpleAuthenticationInfo(user.getPhoneNum(),user.getPassword(), getName()); return authcInfo; }else{ return null; } }
再配一張圖
圖中描述的是使用shiro進行一個完整的登錄過程
所以由以上代碼看出目前我們還沒有發現APP和web登錄d區別,那么區別是什么呢?
web和APP登錄認證的區別
好吧,標題不太准確,應該是登錄的時候和登陸之后會話保持在web和APP之間的區別,先說登錄:
登錄
APP和PC web所需的設備不同很大程度上決定了兩者之間的區別,web一般在PC上瀏覽,登錄的時候使用用戶名和密碼,如果使用了記住密碼就是用cookie認證,web登錄有以下情況
- 第一次登錄,使用用戶名和密碼登錄
- 關閉瀏覽器、session過期,重新使用密碼登錄(如果有記住密碼功能,可以使用cookie登錄)
- 用戶刪除cookie或者cookie過期,使用戶名和密碼登錄
APP在移動設備上查看,第一次登錄的時候使用用戶名和密碼,但是以后如果不是用戶主動退出,都應該保持登錄狀態,這樣才會有更好的用戶體驗,但是不可能一直保留該APP的會話,也不可能把密碼保存在本地,所以APP應該以下的過程
- 第一次登錄,使用用戶名密碼
- 以后用戶打開應用之后,用戶不需輸入密碼系統就可以自動登錄
- 用戶主動退出(重裝等情況視為主動退出)之后,使用用戶名和密碼登錄
貌似沒有看出什么區別,唯一的不同就是第二點:怎么不用密碼登錄,web使用的是cookie(由瀏覽器自動維護的),APP怎么登陸呢?由於APP本地不保存密碼,那么也參考web,使用類似cookie的東西,我們叫他token吧,那問題就解決了,APP本地保存token,為了安全性,定期更新token,那再來看看會話的保持。
會話(session)(保持狀態)
如果用戶登錄了,怎么保持登錄狀態呢,web有cookie和session配合解決這個問題,下面先簡單說一下我對這兩個東西的理解,因為APP會話就是參考這個原理設計的。
cookie:是由瀏覽器維護的,每次請求瀏覽器都會把cookie放在header里面(如果有的話),也可以看做js的可以訪問本地存儲數據的位置之一(另一個就是local storage)
session:由於http是無狀態的,但是有時候服務器需要把這次請求的數據保存下來留給下一次請求使用,即需要維護連續請求的狀態,這個時候服務器就借助cookie,當瀏覽器發送請求來服務器的時候,服務器會生成一個唯一的值,寫到cookie中返回給瀏覽器,同時生成一個session對象,這樣session和cookie值就有了一一對應關系了,瀏覽下一次訪問的時候就會帶着這個cookie值,這個時候服務器就會獲得cookie的值,然后在自己的緩存里面查找是否存在和該cookie關聯的session
因為cookie和session的配合,shiro可以本身很好的支持web的登錄和會話保持,對於APP來說也可以借鑒cookie和session的這種實現方式,唯一存在的問題,就是web的cookie是由瀏覽器維護的,自動將cookie放在header里面,那我們APP只要把服務器返回的cookie放在header里面,每次訪問服務器的時候帶上就可以了。
免密碼登錄
解決了登錄和會話保持的問題,還剩一個免密碼登陸:
web:因為一般網頁主需要記住7天密碼(或者稍微更長)的功能就可以了,可以使用cookie實現,而且shiro也提供了記住密碼的功能,在服務器端session不需要保存過長時間
APP:因為APP免密碼登錄時間需要較長(在用戶不主動退出的時候,應該一直保持登錄狀態),這樣子在服務器端就得把session保存很長時間,給服務器內存和性能上造成較大的挑戰,存在的矛盾是:APP需要較長時間的免密碼登錄,而服務器不能保存過長時間的session,解決辦法:
- APP第一次登錄,使用用戶名和密碼,如果登錄成功,將cookie保存在APP本地(比如sharepreference),后台將cookie值保存到user表里面
- APP訪問服務器,APP將cookie添加在heade里面,服務器session依然存在,可以正常訪問
- APP訪問服務器,APP將cookie添加在heade里面,服務器session過期,訪問失敗,由APP自動帶着保存在本地的cookie去服務器登錄,服務器可以根據cookie和用戶名進行登錄,這樣服務器又有session,會生成新的cookie返回給APP,APP更新本地cookie,又可以正常訪問
- 用戶手動退出APP,刪除APP本次存儲的cookie,下次登錄使用用戶名和密碼登錄
這種方法存在的問題:
- cookie保存在APP本地,安全性較低,可以通過加密cookie增加安全性
- 每次服務器session失效之后,得由APP再次發起登錄請求(雖然用戶是不知道的),但是這樣本身就會增加訪問次數,好在請求數量並不是很大,不過這種方式會使cookie經常更新,反而增加了安全性
這里給出另外一種實現方式:
實現自己的SessionDao,將session保存在數據庫,這樣子的好處是,session不會大量堆積在內存中,就不需要考慮session的過期時間了,對於APP這種需要長期保存session的情況來說,就可以無限期的保存session了,也就不用APP在每次session過期之后重新發送登錄請求了。實現方式如下:
為了使用Hibernate將Session保存到數據庫,新建一個SimpleSessionEntity
package org.lack.entity; import java.io.Serializable; import org.apache.shiro.session.mgt.SimpleSession; import com.phy.em.user.entity.User; public class SimpleSessionEntity { private Long id; private String cookie; private Serializable session; public Long getId() { return id; } public void setId(Long id) { this.id = id; } public Serializable entity() { return session; } public void setSession(Serializable session) { this.session = session; } public String getCookie() { return cookie; } public void setCookie(String cookie) { this.cookie = cookie; } public Serializable getSession() { return session; } }
<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <hibernate-mapping package="org.lack.entity"> <class name="SimpleSessionEntity" table="session"> <!-- 標識 --> <id name="id"> <column name="id"></column> <generator class="increment"></generator> </id> <property name="session"> <column name="session"></column> </property> <property name="cookie"> <column name="cookie"></column> </property> </class> </hibernate-mapping>
以上貼出來的是SimpleSessionEntity的映射文件,特別要注意的是Hibernate也是支持把對象保存在數據庫中的,但是該實體要實現Serializable,在取出來的時候強轉為對應的對象即可,所以這里session的類型為Serializable
新建session緩存的方式的類,這里繼承自EnterpriseCacheSessionDAO,可以使用ehcache作為二級緩存,一定要記得實現save、update、readSession、delete方法,特別是save方法只是保存一個基本的session,重要的attribute都是update的,在readSession中從數據庫中讀取即可
package org.lack.dao import java.io.Serializable; import java.util.Date; import org.apache.log4j.Logger; import org.apache.shiro.session.Session; import org.apache.shiro.session.UnknownSessionException; import org.apache.shiro.session.mgt.SimpleSession; import org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO; import org.springframework.transaction.annotation.Transactional; import com.phy.em.common.dao.IBaseDao; import com.phy.em.common.shiro.entity.SimpleSessionEntity; import com.phy.em.user.entity.User; public class SessionEntityDao extends EnterpriseCacheSessionDAO { private IBaseDao<User> baseDao; private IBaseDao<SimpleSessionEntity> sessionDao; private Logger log = Logger.getLogger(SessionEntityDao.class); @Override public Serializable create(Session session) { // 先保存到緩存中 Serializable cookie = super.create(session); // 新建一個SimpleSessionEntity,然后保存到數據庫 SimpleSessionEntity entity = new SimpleSessionEntity(); entity.setSession((SimpleSession)session); entity.setCookie(cookie.toString()); sessionDao.save(entity); return cookie; } @Override public void update(Session session) throws UnknownSessionException { super.update(session); SimpleSessionEntity entity = getEntity(session.getId()); if(entity != null){ entity.setSession((SimpleSession)session); sessionDao.update(entity); } } @Override public Session readSession(Serializable sessionId) throws UnknownSessionException { Session session = null; try{ session = super.readSession(sessionId); } catch(Exception e){ } // 如果session已經被刪除,則從數據庫中查詢session if(session == null){ SimpleSessionEntity entity = getEntity(sessionId); if(entity != null){ session = (Session) entity.getSession(); } }
// 如果是APP則更新lastAccessTime User user = getUser(sessionId); if(user != null){ // 如果該用戶是APP用戶(user不為空說明就是),則判斷session是否過期,如果過期則修改最后訪問時間 ((SimpleSession)session).setLastAccessTime(new Date()); }
return session; } @Override public void delete(Session session) { super.delete(session); } private User getUser(Serializable sessionId){ String hql = "from User user where user.cookie ='" + sessionId + "'"; return baseDao.findUniqueByHQL(hql); } private SimpleSessionEntity getEntity(Serializable sessionId){ String hql = "from SimpleSessionEntity entity where entity.cookie ='" + sessionId + "'"; return sessionDao.findUniqueByHQL(hql); } private boolean isExpire(Session session){ long timeout = session.getTimeout(); long lastTime = session.getLastAccessTime().getTime(); long current = new Date().getTime(); if((lastTime + timeout) > current){ return false; } return true; } public void setBaseDao(IBaseDao<User> baseDao) { this.baseDao = baseDao; } public void setSessionDao(IBaseDao<SimpleSessionEntity> sessionDao) { this.sessionDao = sessionDao; } }
我快被自己蠢哭了,在繼承EnterpriseCacheSessionDAO 只實現了readSession,妄想自己新建一個SimpleSession來返回給shiro使用,嘗試過很多次之后不行,跟着調試了很多shiro源碼,發現在SimpleSession中Shiro不僅設置了基本的屬性,更重要的是設置了Attribute,但是我自己新建的SimpleSession沒有,所以認證是失敗的,所以在此敬告各位一定要記得實現save和update方法。
雖然走了很多彎路,但是隨着對shiro源碼的調試學習,對shiro了解更深了,不再僅僅停留在只會使用的地步上,有深入。
好了到此為止,正文完了,我們開頭提出的問題都解決完了,記下來掰扯掰扯在做APP登錄過程中遇到的問題以及一些自己的體會。
關於系統安全
在考慮APP登錄的時候考慮了很多安全因素
- 在用戶使用用戶名和密碼登錄的時候,對密碼進行加密
- 會話保持如果使用cookie這種技術的話,存在被別人截取cookie之后就可以認證登錄了
- 在本地保存密碼肯定是不合適的,如果保存cookie(token)的話,手機被root之后,很容易就可以看得到了,比如Android的就只是一個xml文件,所以cookie保存要加密,加密之后提高了破解門檻,加密就涉及到秘鑰的問題了,秘鑰如果寫在代碼里面,java被反編譯之后就很容易秘鑰找得到了,當然了google早就已經開始支持NDK(即Android原生開發,這個原生是指使用C/C++開發,編譯成為so文件,在java中調用),這樣又加大了破解難度,使用Hybrid就更不用說了,直接解壓安裝包就可以看到了。
- cookie如果保存在本地,更新的時機(頻率)是什么,這樣就算是cookie泄露了,也只是在某一段時間內有用(當然了,對於“有心人”來說“這段時間”已經足夠做一些事兒了)
在考慮這些問題的時候我意識到:
- 安全只是相對的(攻與防本來就是一件你強我更強的事,有攻擊,防御就會增強,防御增強了,攻擊要想成功就得更強)
- 安全不是在技術上越安全越好,要考慮實際應用場合、投入的成本(往往不是技術不能實現,而是要考慮實際情況,包括成本、信息的重要程度等等,這就是一種工程思維)