SpringBootShiroRedis 整合實(shí)現(xiàn)用戶認(rèn)證授權(quán)這套組合在中小型項(xiàng)目里實(shí)在太常見了。我自己接過好幾個(gè)這類需求真要說起來踩過的坑不比寫過的代碼少。如果你正準(zhǔn)備給項(xiàng)目加一套登錄鑒權(quán)又不想直接上Spring Security那一大坨配置那Shiro配Redis確實(shí)是個(gè)非常務(wù)實(shí)的選擇。這篇文章就把我實(shí)際整合過程中的思路、配置、代碼和問題排查全部整理出來照著做可以少走很多彎路。1. 整體設(shè)計(jì)與思路拆解1.1 為什么選 Shiro 而不是 Spring Security很多剛開始做認(rèn)證授權(quán)的同學(xué)會(huì)糾結(jié)這個(gè)問題。Spring Security背靠Spring家族功能確實(shí)強(qiáng)大社區(qū)資料也多但它的學(xué)習(xí)曲線偏陡峭過濾鏈的配置邏輯也比較繞新手往往花了兩三天連登錄流程還沒跑通。Shiro的設(shè)計(jì)哲學(xué)則相反它把認(rèn)證、授權(quán)、會(huì)話管理、加密這幾個(gè)核心能力全部抽象成簡單的API概念少、上手快一個(gè)簡單的登錄校驗(yàn)只需要理解Subject、SecurityManager、Realm這三個(gè)核心組件就能跑起來。從實(shí)際項(xiàng)目角度講如果你的系統(tǒng)是標(biāo)準(zhǔn)的單體應(yīng)用用戶量在百萬以下對(duì)安全框架的要求主要是“能快速實(shí)現(xiàn)登錄、記住我、角色權(quán)限控制”那Shiro是完全夠用的。它自帶SessionManager結(jié)合Redis之后還能解決分布式場景下的會(huì)話共享問題已經(jīng)覆蓋了絕大多數(shù)業(yè)務(wù)系統(tǒng)的需求。我見過不少公司內(nèi)部的管理后臺(tái)、運(yùn)營系統(tǒng)、中小型電商后端用的都是這套方案。當(dāng)然Shiro也不是沒有缺點(diǎn)。相比Spring Security它的過濾鏈自定義能力弱一些文檔也不夠細(xì)致遇到一些偏門問題往往要靠翻源碼解決。而且Shiro的社區(qū)活躍度近年有所下降新功能迭代比較慢。選型的時(shí)候你要評(píng)估自己的團(tuán)隊(duì)情況如果大家都沒用過Shiro但熟悉Spring生態(tài)那直接上Spring Security可能反而更順如果項(xiàng)目工期緊、需求簡單或者團(tuán)隊(duì)成員已經(jīng)有Shiro經(jīng)驗(yàn)?zāi)荢hiro這套組合性價(jià)比極高。1.2 引入 Redis 解決了什么問題單機(jī)部署的時(shí)候Shiro自帶的Session管理完全夠用Session數(shù)據(jù)存在JVM內(nèi)存里登錄狀態(tài)直接保存在服務(wù)器本地。可一旦系統(tǒng)需要多節(jié)點(diǎn)部署或者服務(wù)重啟、發(fā)布問題就來了用戶在A節(jié)點(diǎn)登錄下次請(qǐng)求被負(fù)載均衡轉(zhuǎn)發(fā)到B節(jié)點(diǎn)B節(jié)點(diǎn)的內(nèi)存里沒有這個(gè)Session用戶就被判定為未登錄體驗(yàn)非常割裂。傳統(tǒng)的解決方案是Session黏滯讓同一個(gè)用戶的請(qǐng)求始終轉(zhuǎn)發(fā)到同一臺(tái)機(jī)器但這只能算規(guī)避節(jié)點(diǎn)故障或重啟時(shí)問題依然存在。引入Redis之后Session數(shù)據(jù)被集中存儲(chǔ)在外部緩存中所有節(jié)點(diǎn)共享同一份會(huì)話數(shù)據(jù)。用戶無論請(qǐng)求到哪個(gè)節(jié)點(diǎn)都能從Redis正確讀取登錄狀態(tài)。同時(shí)Redis的高讀寫性能讓Session的存取幾乎不影響接口響應(yīng)時(shí)間。除了存SessionRedis還承擔(dān)了權(quán)限緩存的角色。Shiro默認(rèn)每次請(qǐng)求都會(huì)執(zhí)行Realm的授權(quán)方法如果你的授權(quán)邏輯里有數(shù)據(jù)庫查詢?cè)诟卟l(fā)場景下這個(gè)開銷會(huì)被放大。把角色和權(quán)限列表緩存到Redis后同一用戶的權(quán)限校驗(yàn)直接命中緩存大幅減少了數(shù)據(jù)庫的壓力。這套設(shè)計(jì)在真正的生產(chǎn)環(huán)境里效果很明顯我有一次壓測加了Redis緩存之后QPS提升了將近30%。1.3 整體架構(gòu)與數(shù)據(jù)流轉(zhuǎn)過程這套方案的核心數(shù)據(jù)流轉(zhuǎn)可以簡單概括為請(qǐng)求進(jìn)來Shiro過濾鏈判斷是否有登錄憑證有則從Redis中取出Session恢復(fù)用戶的登錄狀態(tài)需要鑒權(quán)時(shí)從Redis緩存取出權(quán)限信息進(jìn)行校驗(yàn)登錄成功后用戶信息和Session寫入Redis退出登錄時(shí)刪除Redis中的會(huì)話數(shù)據(jù)。具體到一次登錄請(qǐng)求的時(shí)序用戶提交用戶名密碼Shiro把請(qǐng)求包裝成一個(gè)UsernamePasswordToken交給SecurityManagerSecurityManager委托給配置好的Realm去做認(rèn)證——Realm里我們寫的是先查數(shù)據(jù)庫用戶信息再用密碼加密規(guī)則比對(duì)密碼認(rèn)證成功后Shiro根據(jù)配置生成Session并存入Redis同時(shí)用戶主體信息也被緩存起來。后續(xù)每次請(qǐng)求經(jīng)過過濾鏈時(shí)Shiro的SessionDAO都會(huì)先去Redis里查這個(gè)Session是否還存在從而判斷用戶是否有效登錄。這套流程把“認(rèn)證”“會(huì)話”“緩存”三個(gè)環(huán)節(jié)通過Redis串起來結(jié)構(gòu)清晰每個(gè)環(huán)節(jié)都可以獨(dú)立做擴(kuò)展。比如后續(xù)要加“記住我”功能只要調(diào)整Cookie和Session的有效期邏輯要加多終端登錄限制也只需在Session管理上做文章。2. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)2.1 Shiro 三大核心組件的工作機(jī)制Shiro的工作模型圍繞Subject、SecurityManager、Realm展開。用生活化的類比來解釋這三者的關(guān)系Subject是“當(dāng)前操作的人”SecurityManager是“門衛(wèi)”Realm是“員工花名冊(cè)”。Subject代表當(dāng)前用戶封裝了用戶的所有安全操作。在代碼里你可以隨時(shí)通過SecurityUtils.getSubject()拿到它然后用subject.login(token)做登錄用subject.isAuthenticated()判斷是否已登錄用subject.hasRole(admin)判斷角色。它本質(zhì)上是Shiro與當(dāng)前線程綁定的一個(gè)上下文對(duì)象簡化了安全操作的調(diào)用方式。SecurityManager整個(gè)Shiro的心臟負(fù)責(zé)協(xié)調(diào)認(rèn)證、授權(quán)、會(huì)話管理等所有內(nèi)部組件。它自己不干活而是把任務(wù)分發(fā)給其他組件執(zhí)行。在SpringBoot整合時(shí)我們需要在配置類里創(chuàng)建一個(gè)SecurityManager的Bean并把它綁定到Shiro的過濾鏈上。Realm數(shù)據(jù)訪問層的橋接器Shiro通過它獲取用戶的認(rèn)證信息和授權(quán)信息。默認(rèn)的Realm什么都不做我們必須寫一個(gè)自定義Realm繼承AuthorizingRealm重寫doGetAuthenticationInfo認(rèn)證時(shí)用和doGetAuthorizationInfo授權(quán)時(shí)用這兩個(gè)方法。這是整個(gè)整合方案里最核心的代碼部分。理解這三個(gè)組件的職責(zé)邊界排起錯(cuò)來會(huì)清晰很多。比如登錄失敗問題大概率出在Realm里的認(rèn)證邏輯權(quán)限校驗(yàn)不通過就要檢查doGetAuthorizationInfo里返回的權(quán)限集合是否正確。2.2 過濾鏈配置anon、authc、roles、perms 的含義Shiro的過濾鏈?zhǔn)峭ㄟ^配置URL和對(duì)應(yīng)的過濾器來實(shí)現(xiàn)訪問控制的這也是它最讓人頭疼但又最靈活的部分。常用的幾個(gè)過濾器要搞清楚anon匿名訪問不需要登錄就可以訪問。通常用來放行登錄接口、注冊(cè)接口、靜態(tài)資源、驗(yàn)證碼接口。authc必須登錄后才能訪問。配置了authc的路徑如果用戶未登錄會(huì)被重定向到登錄頁面或返回未授權(quán)提示。roles必須擁有指定角色才能訪問。它需要參數(shù)比如roles[admin]表示只有admin角色可以訪問。perms必須擁有指定權(quán)限才能訪問同樣需要參數(shù)比如perms[user:add]。配置的順序非常重要。Shiro的過濾鏈?zhǔn)恰暗谝淮纹ヅ鋬?yōu)先”的也就是說一條請(qǐng)求在前面匹配到了anon就會(huì)立刻放行后面的authc根本不會(huì)生效。我見過有同學(xué)把/**authc配置在前面結(jié)果所有請(qǐng)求都要登錄后面配置的放行規(guī)則完全失效。正確的做法是放行規(guī)則寫前面兜底的攔截規(guī)則寫最后具體化的路徑寫前面通配的路徑寫后面。2.3 Redis 在 Shiro 整合中的兩種核心用途Redis這套方案里扮演兩個(gè)完全不同的角色很多人在配置時(shí)容易混淆導(dǎo)致出現(xiàn)一些很隱蔽的問題。第一個(gè)用途是作為Session的存儲(chǔ)介質(zhì)。Shiro把原本存在JVM的Session搬到Redis里需要我們自己實(shí)現(xiàn)一個(gè)RedisSessionDAO繼承AbstractSessionDAO重寫doCreate、doRead、doUpdate、doDelete這幾個(gè)方法。Shiro每次創(chuàng)建、讀取、更新、刪除Session時(shí)都會(huì)調(diào)用這個(gè)DAO。寫入Redis的key我們通常設(shè)計(jì)成shiro_session_xxx這樣的格式value是序列化后的Session對(duì)象。第二個(gè)用途是權(quán)限數(shù)據(jù)的緩存。Shiro的Realm里有一個(gè)AuthorizationCache默認(rèn)內(nèi)存實(shí)現(xiàn)。我們把它替換成RedisCache實(shí)現(xiàn)后用戶權(quán)限信息會(huì)以shiro_cache_xxx的key形式存入Redis緩存有效期可以單獨(dú)設(shè)置。兩種數(shù)據(jù)雖然都放在Redis里但生命周期和用途不一樣建議在Redis的key前綴上做明確區(qū)分避免相互干擾。2.4 序列化方案Java 序列化 vs JSON 序列化把Session對(duì)象和權(quán)限對(duì)象存入Redis之前必須經(jīng)過序列化。這里有個(gè)很多人踩過的坑RedisTemplate默認(rèn)的序列化器是JdkSerializationRedisSerializer它要求存儲(chǔ)的對(duì)象必須實(shí)現(xiàn)Serializable接口。如果你的用戶實(shí)體類沒實(shí)現(xiàn)Serializable運(yùn)行時(shí)就會(huì)拋序列化異常。用Java原生序列化雖然簡單但存儲(chǔ)的內(nèi)容可讀性極差全是亂碼和類路徑信息占用空間也大。更推薦的做法是用FastJson或Jackson做序列化這樣Redis里看到的是清晰的JSON結(jié)構(gòu)排查問題時(shí)一眼就能看出存儲(chǔ)的內(nèi)容。不過要注意用JSON序列化時(shí)從Redis讀出來的對(duì)象是JSON反序列化后的副本不是原來的對(duì)象引用在極端情況下可能存在數(shù)據(jù)一致性問題?？紤]到Session和權(quán)限信息通常是只讀使用這個(gè)權(quán)衡是可以接受的。我在生產(chǎn)環(huán)境里用的是改造過的RedisSessionDAO內(nèi)部統(tǒng)一走JSON序列化這樣Redis里的數(shù)據(jù)鍵值對(duì)一目了然出了問題的定位效率高很多。3. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)3.1 Maven 依賴引入首先在pom.xml里引入必要的依賴。我用的版本組合是經(jīng)過實(shí)際驗(yàn)證的可以直接抄dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.apache.shiro/groupId artifactIdshiro-spring-boot-starter/artifactId version1.9.1/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.apache.commons/groupId artifactIdcommons-pool2/artifactId /dependency dependency groupIdcom.alibaba/groupId artifactIdfastjson/artifactId version2.0.26/version /dependency需要注意shiro-spring-boot-starter這個(gè)依賴在不同版本下的兼容性差異挺明顯。如果你用的是Spring Boot 2.x建議Shiro版本選1.8.x以上1.9.x更穩(wěn)如果你是Spring Boot 3.x那要特別注意Shiro對(duì)Jakarta命名空間的支持問題最好找專門的適配版本。3.2 自定義Realm實(shí)現(xiàn)認(rèn)證與授權(quán)自定義Realm是整套方案的核心代碼。我習(xí)慣創(chuàng)建一個(gè)名為UserRealm的類繼承AuthorizingRealm里面實(shí)現(xiàn)認(rèn)證和授權(quán)兩個(gè)方法。先看認(rèn)證方法Override protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException { UsernamePasswordToken usernamePasswordToken (UsernamePasswordToken) token; String username usernamePasswordToken.getUsername(); // 根據(jù)用戶名查詢數(shù)據(jù)庫 User user userService.findByUsername(username); if (user null) { throw new UnknownAccountException(用戶不存在); } if (user.getStatus() 0) { throw new LockedAccountException(賬號(hào)已被鎖定); } // 返回認(rèn)證信息密碼的比對(duì)由CredentialsMatcher完成 return new SimpleAuthenticationInfo(user, user.getPassword(), ByteSource.Util.bytes(user.getSalt()), getName()); }注意這里有個(gè)關(guān)鍵設(shè)計(jì)我沒有在Realm里手動(dòng)比對(duì)密碼而是把數(shù)據(jù)庫查出的加密密碼返回給Shiro由配置的CredentialsMatcher去自動(dòng)比對(duì)。這樣做的好處是密碼校驗(yàn)邏輯集中管理后續(xù)如果更換加密算法只需要替換Matcher的實(shí)現(xiàn)不影響Realm的其它邏輯。再看授權(quán)方法Override protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) { User user (User) principals.getPrimaryPrincipal(); SimpleAuthorizationInfo info new SimpleAuthorizationInfo(); // 查詢用戶角色 SetString roles roleService.findRolesByUserId(user.getId()); // 查詢用戶權(quán)限 SetString perms permissionService.findPermsByUserId(user.getId()); info.setRoles(roles); info.setStringPermissions(perms); return info; }這個(gè)方法的調(diào)用時(shí)機(jī)很特殊不是每次請(qǐng)求都會(huì)執(zhí)行而是首次訪問需要角色或權(quán)限校驗(yàn)的接口時(shí)才觸發(fā)而且結(jié)果會(huì)被緩存。所以把權(quán)限查詢邏輯寫在這里非常合適配合Redis緩存可以大幅減少數(shù)據(jù)庫查詢。3.3 Shiro 核心配置類編寫配置類負(fù)責(zé)把Realm、SecurityManager、SessionDAO、過濾鏈全部串起來。我直接給出一個(gè)可以運(yùn)行的配置骨架Configuration public class ShiroConfig { Bean public UserRealm userRealm() { return new UserRealm(); } Bean public SecurityManager securityManager(UserRealm userRealm, RedisSessionDAO sessionDAO) { DefaultWebSecurityManager manager new DefaultWebSecurityManager(); manager.setRealm(userRealm); manager.setSessionManager(sessionManager(sessionDAO)); // 開啟Redis緩存權(quán)限數(shù)據(jù) manager.setCacheManager(redisCacheManager()); return manager; } Bean public SessionManager sessionManager(RedisSessionDAO sessionDAO) { DefaultWebSessionManager sessionManager new DefaultWebSessionManager(); sessionManager.setSessionDAO(sessionDAO); // Session有效期單位毫秒這里設(shè)置為2小時(shí) sessionManager.setGlobalSessionTimeout(7200000); return sessionManager; } Bean public ShiroFilterFactoryBean shiroFilterFactoryBean(SecurityManager securityManager) { ShiroFilterFactoryBean factoryBean new ShiroFilterFactoryBean(); factoryBean.setSecurityManager(securityManager); // 登錄接口 factoryBean.setLoginUrl(/api/login); // 未授權(quán)跳轉(zhuǎn)地址 factoryBean.setUnauthorizedUrl(/api/unauthorized); // 過濾鏈配置 MapString, String filterChainDefinitionMap new LinkedHashMap(); // 放行登錄、注冊(cè)、驗(yàn)證碼接口 filterChainDefinitionMap.put(/api/login, anon); filterChainDefinitionMap.put(/api/register, anon); filterChainDefinitionMap.put(/api/captcha, anon); // 靜態(tài)資源放行 filterChainDefinitionMap.put(/static/**, anon); // 用戶相關(guān)接口需要登錄 filterChainDefinitionMap.put(/api/user/**, authc); // 管理員接口需要admin角色 filterChainDefinitionMap.put(/api/admin/**, roles[admin]); // 增加權(quán)限示例 filterChainDefinitionMap.put(/api/user/add, perms[user:add]); // 其余接口需要登錄 filterChainDefinitionMap.put(/**, authc); factoryBean.setFilterChainDefinitionMap(filterChainDefinitionMap); return factoryBean; } }有一處細(xì)節(jié)要提醒filterChainDefinitionMap的類型一定是LinkedHashMap保證有序性。如果用了HashMap過濾鏈的匹配順序會(huì)變得不可預(yù)測表面上看著配置沒問題實(shí)際跑起來卻會(huì)出現(xiàn)各種奇怪的訪問異常。另外CacheManager的Redis實(shí)現(xiàn)需要我們自己寫一個(gè)類繼承AbstractCacheManager創(chuàng)建RedisCache。這個(gè)類的代碼量不大核心是把Cache接口的get、put、remove方法映射到Redis的讀寫刪除操作上。3.4 RedisSessionDAO 與 RedisCache 實(shí)現(xiàn)這部分是整合過程中的硬骨頭直接給出可用的核心實(shí)現(xiàn)。RedisSessionDAO繼承AbstractSessionDAO關(guān)鍵是序列化方式。我選擇用FastJson處理先把Session轉(zhuǎn)成JSON字符串存入Redis讀取時(shí)再反序列化。還有一個(gè)細(xì)節(jié)是key的過期時(shí)間設(shè)置——Session本身有超時(shí)時(shí)間Redis的key也要設(shè)置一個(gè)對(duì)應(yīng)的TTL防止Session永久殘留在Redis里變成臟數(shù)據(jù)。Component public class RedisSessionDAO extends AbstractSessionDAO { Autowired private RedisTemplateString, String redisTemplate; private static final String SESSION_KEY_PREFIX shiro_session:; private static final long SESSION_TIMEOUT 7200L; Override protected Serializable doCreate(Session session) { Serializable sessionId generateSessionId(session); assignSessionId(session, sessionId); saveSession(session); return sessionId; } Override protected Session doReadSession(Serializable sessionId) { String key SESSION_KEY_PREFIX sessionId; String sessionStr redisTemplate.opsForValue().get(key); if (sessionStr null) { return null; } return JSON.parseObject(sessionStr, SimpleSession.class); } private void saveSession(Session session) { String key SESSION_KEY_PREFIX session.getId(); String sessionStr JSON.toJSONString(session); redisTemplate.opsForValue().set(key, sessionStr, SESSION_TIMEOUT, TimeUnit.SECONDS); } Override public void update(Session session) throws UnknownSessionException { saveSession(session); } Override public void delete(Session session) { String key SESSION_KEY_PREFIX session.getId(); redisTemplate.delete(key); } }RedisCache的實(shí)現(xiàn)稍微復(fù)雜主要是把緩存key映射到Redis key并統(tǒng)一管理過期時(shí)間。這里我直接用一個(gè)StringRedisTemplate操作避免序列化器不一致帶來的問題。3.5 登錄接口與退出登錄的實(shí)現(xiàn)登錄接口的邏輯很直觀核心就兩行代碼創(chuàng)建token調(diào)用subject.login。PostMapping(/login) public Result login(RequestBody LoginRequest loginRequest) { Subject subject SecurityUtils.getSubject(); UsernamePasswordToken token new UsernamePasswordToken( loginRequest.getUsername(), loginRequest.getPassword() ); try { subject.login(token); // 登錄成功后可以從subject里拿到用戶信息 User user (User) subject.getPrincipal(); return Result.success(登錄成功, user); } catch (UnknownAccountException e) { return Result.error(用戶不存在); } catch (IncorrectCredentialsException e) { return Result.error(密碼錯(cuò)誤); } catch (LockedAccountException e) { return Result.error(賬號(hào)被鎖定); } catch (AuthenticationException e) { return Result.error(認(rèn)證失敗); } }退出登錄更簡單一行代碼GetMapping(/logout) public Result logout() { Subject subject SecurityUtils.getSubject(); subject.logout(); return Result.success(退出成功); }調(diào)用subject.logout()之后Shiro會(huì)清掉當(dāng)前Subject的身份信息并通過我們實(shí)現(xiàn)的RedisSessionDAO刪除對(duì)應(yīng)的Session數(shù)據(jù)。從Redis里檢查一下key對(duì)應(yīng)的數(shù)據(jù)是否被清掉就能確認(rèn)退出邏輯是否生效。3.6 權(quán)限注解的使用方式除了過濾鏈配置Shiro還支持在接口方法上使用注解來控制權(quán)限粒度更細(xì)用起來也比URL配置更清晰。RestController RequestMapping(/api/user) public class UserController { // 需要登錄才能訪問 RequiresAuthentication GetMapping(/info) public Result getUserInfo() { User user (User) SecurityUtils.getSubject().getPrincipal(); return Result.success(user); } // 需要admin角色 RequiresRoles(admin) PostMapping(/delete) public Result deleteUser(RequestParam Long userId) { userService.deleteById(userId); return Result.success(刪除成功); } // 需要user:add權(quán)限 RequiresPermissions(user:add) PostMapping(/add) public Result addUser(RequestBody User user) { userService.add(user); return Result.success(新增成功); } }使用注解方式有個(gè)先決條件必須在配置類里開啟Shiro注解支持并且確保Shiro的攔截器配置了可代理的目標(biāo)對(duì)象。Spring Boot整合Shiro后默認(rèn)會(huì)通過AOP方式支持注解但需要額外加入一個(gè)Bean配置讓Spring的切面能夠攔截到這些注解。3.7 密碼加密方案的選型與實(shí)現(xiàn)密碼安全是整個(gè)認(rèn)證系統(tǒng)里絕對(duì)不能含糊的部分。早期很多系統(tǒng)直接用MD5存密碼這在如今的安全環(huán)境下是遠(yuǎn)遠(yuǎn)不夠的。我推薦使用MD5加隨機(jī)鹽的方式甚至直接用BCrypt成本低效果好。以MD5加鹽為例注冊(cè)時(shí)生成一個(gè)隨機(jī)salt密碼加密的邏輯如下// 生成隨機(jī)鹽 String salt RandomStringUtils.randomAlphanumeric(8); // 加密迭代次數(shù)可以根據(jù)需要調(diào)整 String encryptedPassword new Md5Hash(rawPassword, salt, 2).toHex();數(shù)據(jù)庫里存儲(chǔ)的是加密后的密碼和鹽。登錄時(shí)Shiro會(huì)通過CredentialsMatcher進(jìn)行密碼比對(duì)我們要在ShiroConfig的UserRealm里設(shè)置對(duì)應(yīng)的MatcherBean public UserRealm userRealm() { UserRealm realm new UserRealm(); // 使用帶鹽的MD5迭代2次 HashedCredentialsMatcher matcher new HashedCredentialsMatcher(); matcher.setHashAlgorithmName(MD5); matcher.setHashIterations(2); realm.setCredentialsMatcher(matcher); return realm; }這里面有一處非常容易踩坑HashedCredentialsMatcher默認(rèn)認(rèn)為數(shù)據(jù)庫里存儲(chǔ)的密碼是Hex字符串如果當(dāng)時(shí)加密用的是Base64或者其他編碼比對(duì)就會(huì)一直失敗。所以注冊(cè)時(shí)的編碼方式和Matcher的預(yù)期必須嚴(yán)格一致改起來很費(fèi)勁。如果要從根本上提高安全性可以直接用BCrypt。BCrypt的哈希自帶鹽不需要額外字段存salt校驗(yàn)時(shí)直接用BCrypt.matches(rawPassword, encryptedPassword)即可。Shiro也有對(duì)應(yīng)的BCryptCredentialsMatcher可以配置。代價(jià)是BCrypt的計(jì)算開銷大一些但對(duì)登錄這種低頻操作來說完全不是問題。4. 整合過程中的常見問題與排查實(shí)錄4.1 Session 失效或每次請(qǐng)求都重新登錄這個(gè)問題的典型表現(xiàn)是前端調(diào)用登錄接口成功了但下一次請(qǐng)求就被過濾鏈攔截判定為未登錄。排查思路先檢查Redis里面有沒有寫入Session數(shù)據(jù)。如果Redis里根本沒有shiro_session開頭的key說明SessionDAO的寫入邏輯沒有被執(zhí)行或執(zhí)行失敗。常見原因有幾種RedisTemplate的序列化配置有問題Session對(duì)象寫入Redis時(shí)報(bào)序列化異常被Shiro內(nèi)部吞掉了。SessionDAO沒有正確注入到SessionManagerShiro還是用的默認(rèn)內(nèi)存Session實(shí)現(xiàn)。檢查配置里sessionManager的setSessionDAO是否真的生效。Cookie的名稱或路徑不對(duì)瀏覽器沒有保存Shiro生成的SessionID。用瀏覽器的開發(fā)者工具看一下請(qǐng)求Cookie的情況。如果是前端部署在另外一個(gè)域名的場景還要考慮Cookie跨域的問題。Shiro默認(rèn)的Cookie只在同域名下有效跨域時(shí)需要配置Cookie的domain屬性或者改成前后端分離模式前端手動(dòng)攜帶SessionID。4.2 密碼一直匹配不上的問題密碼比對(duì)失敗的排查核心是注冊(cè)時(shí)的加密邏輯和登錄時(shí)的校驗(yàn)邏輯必須完全一致。最常見的坑是加鹽方式不對(duì)。注冊(cè)時(shí)用new Md5Hash(password, salt, 2)但登錄時(shí)Matcher拿到的ByteSource如果不一致結(jié)果必然不一樣。在Realm里返回AuthenticationInfo時(shí)鹽的構(gòu)造方式必須和注冊(cè)時(shí)保持一致。比如注冊(cè)時(shí)用的是隨機(jī)字符串salt那么Realm返回時(shí)也要用ByteSource.Util.bytes(user.getSalt())。另外一個(gè)坑是迭代次數(shù)。我遇到過一個(gè)情況數(shù)據(jù)庫表里有歷史數(shù)據(jù)老數(shù)據(jù)的迭代次數(shù)是1次新數(shù)據(jù)是2次結(jié)果老用戶全部登錄失敗。解決思路是漸進(jìn)式遷移登錄成功后檢測當(dāng)前用戶的加密參數(shù)如果是老版本在登錄成功的同時(shí)用新參數(shù)重新加密一遍密碼并更新數(shù)據(jù)庫。4.3 Redis 緩存導(dǎo)致權(quán)限變更不生效這是最容易讓人困惑的問題之一。管理員在后臺(tái)修改了某個(gè)用戶的角色或者權(quán)限但該用戶下次訪問接口時(shí)還是舊權(quán)限甚至需要重啟服務(wù)才生效。原因是權(quán)限信息被緩存到了Redis而且是按用戶維度緩存的。只要不主動(dòng)清理Redis中的緩存會(huì)一直沿用舊數(shù)據(jù)。解決思路有三種在權(quán)限變更的接口里主動(dòng)清理對(duì)應(yīng)用戶權(quán)限的緩存。需要拿到權(quán)限緩存Manager調(diào)用clearCache方法。給權(quán)限緩存設(shè)置較短的過期時(shí)間比如30分鐘犧牲一些性能換取準(zhǔn)實(shí)時(shí)性。在權(quán)限變更后強(qiáng)制該用戶重新登錄通過登錄流程重建權(quán)限緩存。實(shí)際項(xiàng)目里我比較推薦第一種思路在業(yè)務(wù)代碼里預(yù)留緩存清理邏輯。雖然要多寫一點(diǎn)代碼但權(quán)限變更的響應(yīng)是幾乎實(shí)時(shí)的運(yùn)營和管理同事的體驗(yàn)會(huì)好很多。4.4 RedisSessionDAO 反序列化報(bào)錯(cuò)這種情況在Session數(shù)據(jù)是舊版本寫入、代碼升級(jí)后重新讀取時(shí)容易發(fā)生。比如之前用Java原生序列化寫入的Session代碼改成JSON序列化后舊的Redis數(shù)據(jù)還在新代碼嘗試用JSON解析直接拋異常。解決思路是平滑升級(jí)改代碼之前先把Redis里的Session數(shù)據(jù)一次性清掉。發(fā)布時(shí)設(shè)置session的有效期短一些讓舊Session盡快過期。更好的方案是代碼里做兼容處理讀數(shù)據(jù)失敗時(shí)catch異常并返回null讓Shiro對(duì)這個(gè)Session重新走創(chuàng)建流程。4.5 權(quán)限注解不生效的排查在Spring Boot項(xiàng)目里啟用Shiro注解需要確認(rèn)兩個(gè)方面一是自定義Realm的Bean必須被Spring管理二是Shiro的注解掃描需要開啟。常見的配置是引入一個(gè)AuthorizationAttributeSourceAdvisor的Bean它的作用是把Shiro的注解和Spring AOP關(guān)聯(lián)起來。如果配置了還是不生效優(yōu)先檢查是不是類沒有被Spring掃描到或者接口方法用了private修飾。Shiro的注解是通過AOP代理實(shí)現(xiàn)的private方法是不會(huì)走代理的所以注解必須放在public方法上。5. 這個(gè)方案的擴(kuò)展與優(yōu)化方向5.1 基于 Redis 的限流與防刷既然Redis已經(jīng)集成進(jìn)來了順手加一個(gè)接口防刷的機(jī)制是很自然的擴(kuò)展。在登錄接口上做限制比如同一個(gè)IP一分鐘內(nèi)最多嘗試5次登錄超過則直接拒絕。實(shí)現(xiàn)也不復(fù)雜用Redis的INCR和EXPIRE命令就能搞定。String key login:limit: ipAddress; Long count redisTemplate.opsForValue().increment(key); if (count ! null count 1) { redisTemplate.expire(key, 1, TimeUnit.MINUTES); } if (count ! null count 5) { throw new RuntimeException(登錄嘗試次數(shù)過多請(qǐng)稍后再試); }這個(gè)邏輯放在登錄接口的最前面攔截效果非常直接。它也是目前很多互聯(lián)網(wǎng)產(chǎn)品在用的登錄防暴力破解手段。5.2 記住我功能與退出策略Shiro自帶RememberMe功能開啟后用戶關(guān)閉瀏覽器SessionId仍然保存在本地Cookie中下次訪問自動(dòng)恢復(fù)登錄狀態(tài)。Redis的引入讓RememberMe的實(shí)現(xiàn)更有優(yōu)勢(shì)因?yàn)镾ession數(shù)據(jù)在Redis里即使用戶換了節(jié)點(diǎn)只要Cookie中的SessionId還在依然能正確恢復(fù)登錄狀態(tài)。實(shí)現(xiàn)RememberMe需要在登錄時(shí)設(shè)置token的rememberMe屬性為true并在SecurityManager中配置一個(gè)rememberMeManager把Cookie的有效期調(diào)長。要注意的是RememberMe狀態(tài)下subject.isAuthenticated()為false但subject.isRemembered()為true。如果你的代碼里用isAuthenticated()做判斷未真正登錄就拒絕訪問的接口需要特別注意這個(gè)細(xì)節(jié)。5.3 集群環(huán)境下的多節(jié)點(diǎn)會(huì)話一致性這套方案在集群環(huán)境下的表現(xiàn)是比較理想的。因?yàn)樗蠸ession數(shù)據(jù)都存在Redis每個(gè)節(jié)點(diǎn)讀到的都是同一份數(shù)據(jù)天然解決了會(huì)話一致性的問題。唯一要注意的是多個(gè)節(jié)點(diǎn)共享同一個(gè)Redis時(shí)序列化配置必須一致否則A節(jié)點(diǎn)寫入的數(shù)據(jù)會(huì)被B節(jié)點(diǎn)反序列化失敗。另一個(gè)要考慮的點(diǎn)是Redis的持久化策略要對(duì)齊公司的運(yùn)維規(guī)范。如果Redis是純緩存模式、允許數(shù)據(jù)丟失那么Redis重啟后所有用戶會(huì)集體掉線必須重新登錄。如果希望高可用可以開啟Redis的持久化或者用主從模式哨兵。這塊屬于運(yùn)維范疇但在方案設(shè)計(jì)階段就應(yīng)該想清楚免得后面上線時(shí)出大問題。6. 實(shí)操心得總結(jié)這套SpringBootShiroRedis的方案我從第一次接觸到今天前前后后在好幾個(gè)項(xiàng)目里落地過。回過頭來看最核心的收獲是技術(shù)選型一定要結(jié)合團(tuán)隊(duì)的實(shí)際能力和項(xiàng)目的真實(shí)規(guī)模不要為了炫技去選一個(gè)用不上的框架。Shiro在中小型項(xiàng)目里依然是非常能打的方案搭配Redis之后的分布式會(huì)話能力完全夠用。而且它最大的優(yōu)勢(shì)在于概念直觀新同學(xué)上手速度快出現(xiàn)問題后定位路徑非常短。相比Spring Security同樣的功能在Shiro里的實(shí)現(xiàn)代碼量大概能少30%到40%這在項(xiàng)目周期緊的時(shí)候是實(shí)打?qū)嵉膬?yōu)勢(shì)。有一點(diǎn)我覺得值得養(yǎng)成習(xí)慣正式上線前一定要對(duì)認(rèn)證授權(quán)模塊做一次專門的測試重點(diǎn)覆蓋Session過期、權(quán)限變更、多節(jié)點(diǎn)切換、并發(fā)登錄這幾個(gè)場景。這些邊角問題在單機(jī)開發(fā)和測試環(huán)境里很難暴露但一旦上了生產(chǎn)用戶報(bào)障的往往就是這類問題。最后再分享一個(gè)排查小技巧如果你在整合過程中碰到了詭異的Session、權(quán)限問題第一步永遠(yuǎn)是去Redis里看看數(shù)據(jù)是什么樣的。數(shù)據(jù)在問題就在讀數(shù)據(jù)的環(huán)節(jié)數(shù)據(jù)不在問題就在寫數(shù)據(jù)的環(huán)節(jié)。這比反復(fù)看代碼猜原因高效得多。