應用場景
SpringSecurityOAuth2有一個奇葩的設計，那就是它將與access_token相關的所有屬於都封裝到OAuth2AccessToken中，然後保存時會直接將該對象序列化成字節寫入數據庫。我們在資源服務器中想要直接讀數據庫來取出access_token來驗證令牌的有效性，然而又不想引入SpringSecurity的相關依賴污染jar包。這時可以將SpringSecurity中OAuth2AccessToken的唯一實現類DefaultOAuth2AccessToken的源碼copy到我們的項目中，然後通過JDBC讀取byte[],通過JDK自帶的反序列化機制來還原DefaultOAuth2AccessToken對象。這時就會遇到問題，即原來的OAuth2AccessToken所在包是以org.springframework.security開頭的，而我們copy過來源碼後，包名是以我們自己定義的包cn.com.XXXX開頭的，這樣在反序列化時，即使兩個類的字段完全一樣，但由於字節流中存儲的類信息的全限定性名不同，也會導致反序列化失敗。
解決方案
我們可以定義子類繼承JDK的ObjectInputStream，然後重寫readClassDescriptor()方法：
@Override protected ObjectStreamClass readClassDescriptor() throws IOException, ClassNotFoundException {ObjectStreamClass read = super.readClassDescriptor();if (read.getName().startsWith("原包名")) {Class type = Class.forName(read.getName().replace("新包名"));return ObjectStreamClass.lookup(type);}return read;}這樣在反序列化時就不會報錯了。原理並不復雜，其實就是在解析字節流時，將解析後應為org.springframework.security.oauth2.common.DefautOAuthToken的class，替換成了我們自己copy過來源碼的cn.com.XXXXXX.DefaultOAuthToken從而達到”欺騙”的目的。在該場景下，我們就可以做到在資源提供方不引入SpringSecurity框架而只使用SpringSecurityOAuth2的授權服務。資源提供方直接讀數據庫來驗證令牌的有效性，而不是向授權服務查詢。
總結
以上就是本文關於JDK反序列化時修改類的全限定性名解析的全部內容，希望對大家有所幫助。感興趣的朋友可以繼續參閱本站其它相關專題，如有不足之處，歡迎留言指出。感謝朋友們對本站的支持！