في الآونة الأخيرة ، كنت أعمل في مشروع التطبيق. لقد طورته بمفرده في الخلفية. لم يتم تضمين الوظائف الأساسية لتسجيل الدخول والتسجيل والتحقق من الإذن في المرحلة الأولى من التطوير بترتيب مهام التنمية. الآن تم الانتهاء من بعض الوظائف المتعلقة بالأعمال ، ولكن لم يتم تنفيذ بوابة المستخدم بعد. يوضح هذا فقط أنني كنت قلقًا للغاية عندما قمت بتحليل المتطلبات لأول مرة ووضعت بوابة المستخدم الأساسية وراءها.
تحتاج الآن إلى إضافة وظائف تسجيل دخول المستخدم والتحقق من الإذن بناءً على الرمز الموجود.
فيما يتعلق بالتحقق من تسجيل الدخول والإذن ، بالإشارة إلى تجربة تطوير iOS السابقة ، يوفر جانب التطبيق اسم المستخدم وكلمة المرور لتبادل الرموز المميزة ، ويحتاج إذن تسجيل الدخول لكل طلب من خلال الرمز المتبادل.
الآن ، من ناحية أخرى ، أحتاج إلى النظر في القضايا التالية:
1. كيفية تلبية تنفيذ هذه الوظائف بسهولة في رمز الوظائف الحالية ، بحيث لا يتم تغيير الكود الحالي ، ولن يكون هناك أي متاعب لتنفيذ التحقق من الإذن في المستقبل.
2. كيفية إنشاء الرموز المميزة على أساس اسم المستخدم وكلمة المرور ، وكيفية التمييز بين صحة العميل لتوفير الرموز في الوظائف التي تتطلب أذونات
بادئ ذي بدء ، في مواجهة المشكلة الأولى ، وفقًا للتجربة ، فإن الحل التقليدي هو المرشحات والاعتراضات. إذا تم وضع تسجيل الدخول والإذن في ترتيب المتطلبات ، طالما تم إعطاء عناوين URL للوظائف اللاحقة نمطًا معينًا ، فسيكون استخدام المرشحات أو التقاطعات ناجحة. لكنني الآن أواجه عناوين URL التي ليس لها تصميم أو مواصفات في المرحلة المبكرة ، لذلك لا أريد مواجهة استخدام المرشحات أو التقاطعات.
بالإضافة إلى الحلول التقليدية المذكورة أعلاه ، أصبح Spring AOP سلاحًا لحل هذا النوع من المشكلات. يستخدم برمجة متوترة للوجه لتوفير عملية تسوية مسبقة لجميع الطرق التي تتطلب التحقق من الإذن. ومع ذلك ، نظرًا لأن عنوان URL أو اسم الفصل أو الطريقة غير منتظم ، فكرت في التعليق التوضيحي المخصص والتحقق من أذونات لجميع الطرق التي تضيف التعليقات التوضيحية المخصصة.
1. بما أنك فكرت بالفعل في استخدام Spring AOP ، فإن الخطوة الأولى هي تمكين AOP في ملف تكوين الربيع
// افتح AOP
<aOP: SideJ-Autoproxy />
يعتمد التكوين أعلاه على حزم جرة ذات صلة بأوب من الربيع في المشروع ، وإدخال عنوان UP في AOP في رأس ملف التكوين.
2. بعد ذلك ، دعونا نحدد التعليق التوضيحي المخصص أولاً
target ({elementType.method ، elementType.type}) @entry (enthinationpolicy.runtime) public interface userAccess {}3. لا يمكننا أن نسرع في القيام بوظائف التحقق من الإذن ، لأن الرمز المميز لم يولد حلاً بعد.
من أجل توليد الرمز المميز ، يتم النظر في علامة واحدة ، لذلك لا يمكن إصلاح الرموز طوال الوقت. خلاف ذلك ، في أي وقت ، طالما كان لديك رمز ، يمكنك استخدام نفس الحساب على الأقل شخصين في نفس الوقت ، وهو أمر غير مسموح به في أعمالنا في الوقت الحالي. في النهاية ، اخترت "اسم المستخدم + كلمة المرور + وقت تسجيل الدخول" للقيام بتشفير MD5 كرمز مميز (هناك العديد من الطرق ، مثل UUID عند ضمان التفرد والتكيف). قم بإنشاء الرموز المميزة عند التحقق من اسم المستخدم وكلمة المرور بنجاح ، وحفظ الرمز المميز في شكل أزواج ذات قيمة رئيسية من "اسم المستخدم: الرمز المميز" و "الرمز المميز: المستخدم" (يمكن حفظها أيضًا في قاعدة البيانات) ، وأخيراً إرجاع الرمز المميز إلى العميل.
الرمز التالي هو مجرد مثال بسيط:
servicepublic class loginservice {/*** store "اسم المستخدم: رمز" زوج مفتاح القيمة*/الخريطة الثابتة العامة <string ، string> tokenmap = new hashmap <string ، string> () ؛/*** store "token: user" user-value pair*/public static map <string ، user> loginusermap = تسجيل الدخول إلى السلسلة العامة (اسم السلسلة ، كلمة مرور السلسلة) {system.out.println (name+"-----"+كلمة المرور) ؛/*** تحقق مما إذا كان تسجيل الدخول ناجحًا* 1. تسجيل الدخول بنجاح* 1.1. ناجح بإنشاء الرمز والتحديث المقابل * 1.2. قم برمي استثناء إذا فشل*/string token = tokenmap.get (name) ؛ user user = null ؛ if (token == null) {user = new user () ؛ user.setName (name) ؛ user.setPassword (password) ؛ system.out.println ("user user new user تسجيل الدخول ") ؛} آخر {user = loginusermap.get (token) ؛ loginusermap.remove (token) ؛ system.out.println (" update update order login token ") ؛} token = md5util.md5 (name+password+new date (). token) ؛ system.out.println ("حاليًا"+tokenmap.size ()+"المستخدمين") ؛ لـ (user u: loginusermap.values ()) {system.out.println (U.GetName ()+":4. في الوقت نفسه ، حصل عميلنا على رمز رمز بعد تسجيل الدخول. طالما أننا نحمل الرمز المميز في جميع الطلبات التي تتطلب إذنًا ، يمكننا الحصول على الاستجابة بنجاح (اقتراح: لتسهيل ترميز التطبيق ، يمكن أن يتم تنفيذ الرمز المميز في المستقبل). لقد وجدت للتو طريقة لإجراء تجربة:
@controller@requestmapping ("/login") logincontroller {AUTOWiredPrivate loginservice loginService ؛ userAccess @requestMapping (value = "/loginin" ، method = requestMethod.get) publicResponsebody String Login (httpservletrequest request) {string name = request.getParameter ("name")لاحظ أن الجزء الجريء هو تخصيص التعليق التوضيحي. من المستحيل أن يكون لديك رموز لمعلمات الطلب لوظيفة تسجيل الدخول ، لذلك بغض النظر عن عدد المرات التي يتم التحقق منها ، لا يمكن تمريرها. فقط قدم مثالا. userAccess إضافة أعمال فقط على الوظيفة التي تتطلب التحقق من الإذن
5. التعليق التوضيحي المخصص هو الآن نقطة دخول جيدة
@component@SidePublic Class SermissionAspect {// قم بتعيين التعليقات التوضيحية المخصصة كنقطة إدخال@before ("@enoTation (com.example.chap01.annotation.userAccess)") joinpoint.getargs () ؛ httpservletrequest طلب = (httpservletrequest) args [0] user = loginservice.loginusermap.get (token) ؛ if (user == null) {system.out.println ("لا يتم تمرير التحقق!") ؛ رمي استثناء جديد ("لا إذن") ؛}}}}في هذه المرحلة ، يتم الانتهاء من وظائف التحقق من تسجيل الدخول والإذن.
بالإضافة إلى ذلك ، يتم إرفاق رمز المصدر على Github الشخصية: https://github.com/zw201913/applogin.git
ما سبق هو كل شيء عن هذا المقال ، آمل أن يكون مفيدًا لتعلم الجميع.