سيناريوهات التطبيق
لدى SpringSecurityoauth2 تصميمًا غريبًا ، أي أنه يلف جميع العقارات المتعلقة بـ Access_token في Oauth2AccessToken ، ثم عند حفظها ، فإنه سيؤدي إلى تخصيص الكائن مباشرة في بايت وينتسب إلى قاعدة البيانات. نريد قراءة قاعدة البيانات مباشرة في خادم الموارد لاسترداد Access_Token للتحقق من صحة الرمز المميز ، لكننا لا نريد تقديم حزم جرة التبعية المتعلقة بالأمن. في هذا الوقت ، يمكنك نسخ الكود المصدري لفئة التنفيذ الوحيدة DefaultOauth2AccessToken في SpringSecurity في مشروعنا ، ثم قراءة البايت [] من خلال JDBC ، واستعادة كائن DefaultoAuth2AccessToken من خلال آلية تفضيل JDK الخاصة. في هذا الوقت ، ستواجه مشكلة ، أي أن حزمة Oauth2AccessToken الأصلية تبدأ بـ org.springframework.security ، وبعد أن نسخب الكود المصدري ، يبدأ اسم الحزمة بالحزمة cn.com.xxxx ، التي نحددها أنفسنا. وبهذه الطريقة ، عند إلغاء التخلص ، حتى لو كانت حقول الفئتين متشابهة تمامًا ، فإن فشل التخلص من التالي سيكون ناتجًا عن أسماء مختلفة مؤهلة بالكامل لمعلومات الفصل المخزنة في دفق البايت.
حل
يمكننا تحديد الفئة الفرعية وراثة كائن JDK ObjectInputStream ، ثم تجاوز طريقة ReadClassDescriptor ():
OverRide محمي ObjectStreamClass ReadClassDescriptor () يلقي ioException ، classnotfoundException {ObjectStreamClass read = super.readclassdescriptor () ؛ if (read.getName () ObjectStreamClass.lookup (type) ؛} return read ؛}بهذه الطريقة ، لن تكون هناك أخطاء عند إلغاء التخلص منها. المبدأ غير معقد. في الواقع ، عند تحليل دفق البايت ، يتم استبدال الفصل الذي يجب تحليله كـ org.springframework.security.oauth2 في هذا السيناريو ، لا يمكننا إلا استخدام خدمة ترخيص Springsecurityoauth2 دون تقديم إطار عمل SpringSecurity في مزود الموارد. يقرأ مزود الموارد قاعدة البيانات مباشرة للتحقق من صحة الرمز المميز ، بدلاً من الاستعلام عن الخدمة المعتمدة.
لخص
ما سبق هو المحتوى الكامل لهذه المقالة حول دقة الاسم المؤهلة الكاملة للفئات المعدلة خلال إزالة الجهد JDK. آمل أن يكون ذلك مفيدًا للجميع. يمكن للأصدقاء المهتمين الاستمرار في الرجوع إلى الموضوعات الأخرى ذات الصلة على هذا الموقع. إذا كانت هناك أي أوجه قصور ، فيرجى ترك رسالة لإشارةها. شكرا لك يا أصدقائك لدعمكم لهذا الموقع!