JDK反序列化时修改类的全限定性名解析

Applicazione

SpringSecurityOAuth2 ha un design curioso, ovvero esso impacchetta tutte le entità correlate a access_token all'interno di OAuth2AccessToken e li serializza direttamente in byte e li scrive nel database durante la conservazione. Nel server delle risorse, vogliamo leggere direttamente il database per estrarre l'access_token per verificare la validità del token, ma non vogliamo introdurre dipendenze di SpringSecurity che possano contaminare il jar. In questo caso, possiamo copiare il codice sorgente dell'implementazione unica di OAuth2AccessToken in SpringSecurity, DefaultOAuth2AccessToken, nel nostro progetto e leggere byte[] tramite JDBC, poi utilizzare il meccanismo di deserializzazione nativo di JDK per ripristinare l'oggetto DefaultOAuth2AccessToken. In questo modo, ci imbatteremo in un problema, ovvero il pacchetto in cui OAuth2AccessToken era situato aveva come prefisso org.springframework.security, mentre dopo aver copiato il codice sorgente, il nome del pacchetto inizia con il nostro nome di pacchetto definito cn.com.XXXX. Questo può causare un fallimento nella deserializzazione, anche se i campi delle due classi sono completamente identici, poiché il nome completo della classe memorizzato nel flusso di byte è diverso.

Soluzione

Possiamo definire una sottoclasse che eredita da JDK's ObjectInputStream e poi sovrascrivere il metodo readClassDescriptor():

@Override
    protected ObjectStreamClass readClassDescriptor() throws IOException, ClassNotFoundException {
	ObjectStreamClass read = super.readClassDescriptor();
	if (read.getName().startsWith("vecchio pacchetto nome")) {
		Class type = Class.forName(read.getName().replace("nuovo pacchetto nome"));
		return ObjectStreamClass.lookup(type);
	}
	return read;
}

In questo modo, non verranno generati errori durante la deserializzazione. Il principio non è complicato, in realtà si tratta di sostituire la class org.springframework.security.oauth2.common.DefautOAuthToken che dovrebbe essere analizzata dal flusso di byte con la nostra copia del codice sorgente cn.com.XXXXXX.DefaultOAuthToken per raggiungere lo scopo di "ingannare". In questo scenario, possiamo raggiungere l'obiettivo di utilizzare solo il servizio di autorizzazione SpringSecurityOAuth2 senza introdurre il framework SpringSecurity sul lato fornitore delle risorse. Il lato fornitore delle risorse legge direttamente il database per verificare la validità del token, invece di consultare il servizio di autorizzazione.

Sommario

Questo è tutto il contenuto di questo articolo sull'analisi del nome qualificato della classe durante la deserializzazione di JDK, spero sia utile a tutti. Chi è interessato può continuare a leggere altri argomenti correlati su questo sito, e sono benvenuti i commenti sugli aspetti insufficienti. Grazie per il supporto dei amici di questo sito!

Dichiarazione: il contenuto di questo articolo è stato raccolto da Internet, il copyright è della proprietà del rispettivo autore, il contenuto è stato contribuito e caricato volontariamente dagli utenti di Internet, questo sito non possiede il diritto di proprietà, non è stato elaborato manualmente e non assume alcuna responsabilità legale. Se trovi contenuti sospetti di violazione del copyright, ti preghiamo di inviare una e-mail a: notice#oldtoolbag.com (al momento dell'invio dell'e-mail, sostituisci # con @) per segnalare e fornire prove pertinenti. Una volta verificata, questo sito rimuoverà immediatamente i contenuti sospetti di violazione del copyright.