JDK反序列化時修改類的全限定性名解析
應(yīng)用場景
SpringSecurityOAuth2有一個奇葩的設(shè)計(jì),那就是它將與access_token相關(guān)的所有屬于都封裝到OAuth2AccessToken中,然后保存時會直接將該對象序列化成字節(jié)寫入數(shù)據(jù)庫。我們在資源服務(wù)器中想要直接讀數(shù)據(jù)庫來取出access_token來驗(yàn)證令牌的有效性,然而又不想引入SpringSecurity的相關(guān)依賴污染jar包。這時可以將SpringSecurity中OAuth2AccessToken的唯一實(shí)現(xiàn)類DefaultOAuth2AccessToken的源碼copy到我們的項(xiàng)目中,然后通過JDBC讀取byte[],通過JDK自帶的反序列化機(jī)制來還原DefaultOAuth2AccessToken對象。這時就會遇到問題,即原來的OAuth2AccessToken所在包是以org.springframework.security開頭的,而我們copy過來源碼后,包名是以我們自己定義的包c(diǎn)n.com.XXXX開頭的,這樣在反序列化時,即使兩個類的字段完全一樣,但由于字節(jié)流中存儲的類信息的全限定性名不同,也會導(dǎo)致反序列化失敗。
解決方案
我們可以定義子類繼承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; }
這樣在反序列化時就不會報錯了。原理并不復(fù)雜,其實(shí)就是在解析字節(jié)流時,將解析后應(yīng)為org.springframework.security.oauth2.common.DefautOAuthToken的class,替換成了我們自己copy過來源碼的cn.com.XXXXXX.DefaultOAuthToken從而達(dá)到”欺騙”的目的。在該場景下,我們就可以做到在資源提供方不引入SpringSecurity框架而只使用SpringSecurityOAuth2的授權(quán)服務(wù)。資源提供方直接讀數(shù)據(jù)庫來驗(yàn)證令牌的有效性,而不是向授權(quán)服務(wù)查詢。
總結(jié)
以上就是本文關(guān)于JDK反序列化時修改類的全限定性名解析的全部內(nèi)容,希望對大家有所幫助。感興趣的朋友可以繼續(xù)參閱本站其它相關(guān)專題,如有不足之處,歡迎留言指出。感謝朋友們對本站的支持!
相關(guān)文章
Tomcat 實(shí)現(xiàn)WebSocket詳細(xì)介紹
這篇文章主要介紹了Tomcat 如何實(shí)現(xiàn)WebSocket的相關(guān)資料,對WebSocket協(xié)議通信的過程進(jìn)行了詳細(xì)介紹,需要的朋友可以參考下2016-12-12IDEA mybatis-generator逆向工程生成代碼
這篇文章主要介紹了IDEA mybatis-generator逆向工程生成代碼,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2018-06-06Java中IO流之字符流與字節(jié)流的轉(zhuǎn)換方式
在Java中,字節(jié)流與字符流是處理數(shù)據(jù)的兩種方式,字節(jié)流適用于處理各種數(shù)據(jù)類型,如圖片、音頻等非文本數(shù)據(jù),而字符流專門用于處理文本數(shù)據(jù),Java提供了InputStreamReader和OutputStreamWriter這兩個類來實(shí)現(xiàn)字節(jié)流向字符流的轉(zhuǎn)換2024-10-10