لا تزال وظيفة تسجيل الدخول الفردي مهمة للغاية في سيناريوهات التطبيق الفعلية. من الناحية المنطقية ، لا نسمح للمستخدم بإجراء عمليتين في نفس الوقت. دعنا نتعرف على تطبيق SPRINGMVC.
يختلف اعتراض SPRINGMVC عن اعتراض الربيع. SpringMVC لديه مرسلات دخول موحدة. تمر جميع الطلبات عبر Dispatcherservlet ، لذلك تحتاج فقط إلى إثارة ضجة على مرسلات Servatcherservlet. لا يحتوي Dispatcherservlet على وكيل ، ولا يحتوي وحدة التحكم التي تديرها SPRINGMVC على وكيل.
1. استكشاف مبدأ التنفيذ الأساسي أولاً: هذه الوظيفة بسيطة نسبيًا ، أي أن مستخدمًا واحدًا فقط يمكنه العمل على نفس مشروع الويب في نفس الوقت ، لذلك هنا اكتشاف تسجيل الدخول عن بُعد ، ويتم تقديم مسارين هنا. 1. يكتشف الخادم أن المستخدم المسجل في تشغيل عملية تسجيل الدخول مرة أخرى من خلال IP آخر ، ثم يدفع تذكيرًا بنشاط لإخبار المستخدم الأول بتسجيل الدخول إلى تسجيل الدخول عن بُعد ؛ 2. عندما يقوم المستخدم بعمليات ، يجد أن حسابه قد تم ضغطه وهناك تسجيل دخول عن بُعد. فيما يتعلق هذين الحلتين ، فإن أول حل هو في الوقت الفعلي ولكن لا يزال يتم استكشافه. دعنا نركز على الطريقة الثانية أدناه.
2. تنفيذ النوع الثاني بسيط نسبيا. هناك عمليتان. أحدهما هو إضافة حقل إضافي إلى SessionId الخاص بالمستخدم لتخزين SessionId الذي تم تسجيل الدخول إليه ، لأن كل طلب طلب يتوافق مع SessionId فريد من نوعه. ثم ، باستخدام تقنية Interceptor ، واعتراض عمليات المستخدم. في المعترض ، يتم إصدار طلب عنوان URL ذي الصلة على صفحة تسجيل الدخول لأول مرة ، والآخر هو طلب التحقق من تسجيل الدخول. وأخيرا ، تصفية المستخدم. (حول تسجيل الدخول إلى المستخدم ، عندما يكون التحقق من النجاح ، ليس فقط إذا تم تخزين المستخدم في جلسة التحقق من اعتراض تسجيل الدخول ، ولكن أيضًا يجب تخزين معرف الجلسة في SessionId المقابل في جدول المستخدم.) لطلب الطلب هذا الوقت ، يمكنك الحصول على الجلسة ومعرفه ثم مقارنة ما إذا كان SessionId في قاعدة البيانات وفقًا للمعرف هذا ، ثم تمرير الإصدار. إذا كان الاختلاف هو ، فسيتم مطالبة تسجيل دخول القفزة في وضع عدم الاتصال بالقفز في تسجيل الدخول ، لأنه ستكون هناك جلسة في عملية خادم اتصال المستخدم. طالما تنتهي صلاحية الجلسة ، فإن معرف جلسة كل مستخدم يبدأ العملية هو نفسه ، لذلك سوف يتطابق مع المعرف المخزّن في قاعدة البيانات عند تسجيل الدخول. عندما يمر شخص آخر عبر الأجهزة الأخرى ، استخدم نفس الحساب للدخول. سيتم إعادة تأسيس الجلسة عند تسجيل الدخول. ستقوم الجلسة في قاعدة البيانات بتحديث SessionId في قاعدة البيانات ، لكن SessionId لا يزال دون تغيير. ومع ذلك ، تغيرت الجلسة في قاعدة البيانات. لذلك ، عند التحقق مما إذا كان SessionId في قاعدة البيانات متسقًا في الاعتراض ، سيفشل في اعتراض تشغيل المستخدم لتحقيق وظيفة تسجيل الدخول المستخدم الواحد. (ملاحظة حول الجلسة ، عندما يتصل المستخدم لأول مرة بالخادم ، سيتم إنشاء جلسة على جانب الخادم ، ثم ستحمل كل عملية بدء تشغيل المستخدم معرف هذه الجلسة ، وسوف تحدث بعض المواقف. لم يتم تشغيل المستخدم مع الخادم لفترة طويلة. يقوم المستخدم بتسجيل الخروج وتجعل الجلسة بفعالية.
ما يلي هو تنفيذ التقاطع في springMVC
الطبقة العامة SingleUserInterceptor تنفذ معالج {autowiredprivate usermapper mapper ؛ public void aftercompletion (httpservletrequest arg0 ، httpservletresponse arg1 ، object arg2 ، استثناء arg3) استثناء {// todo method method reghandle posthandle (httttpledrequest ، {todo todo tudo tudo} proboed posthandle (htttttppledrequest ، HttPservletResponse Arg1 ، Object Arg2 ، ModelAndview Arg3) يرمي الاستثناء {// todo method method method ad} preplean properle (httpservletrequest arg0 ، httpservletsponse arg1 ، object arg2) يلقي استثناء {string url = arg0.getrequesturi () ؛ if (url.indexof ("login.jsp")> = 0 || url.indexof ("new/login")> = 0 || url.indexof ("checkUser")> = 0) {return true ؛} // إذا كان اسم المستخدم موجودًا (أي تسجيل الدخول والإصدار) user user = (integer) arg0.getSession (). getAttribute ("user") ؛ if (user! = null) {string sessionid = mapper.getuserentity (integer.valueof (user)). Else {arg1.setStatus (arg1.sc_gateway_timeout) ؛ arg1.setContentType ("text/html ؛ charset = utf-8") ؛ printWriter out = arg1.getWriter () ؛ out.println ("<html>") ؛ في مكان آخر ، أنت مضطر للذهاب إلى عدم الاتصال ")")) arg0.getRequestDispatcher ("login.jsp"). إلى الأمام (Arg0 ، Arg1) ؛ return false ؛}} arg0.getRequestDispatcher ("login.jsp").يمكن أن يدرك الرمز أعلاه وظيفة المستخدم الأول الذي تم تسجيل الدخول الذي يتم ضغطه خارج الخط عندما يقوم المستخدم نفسه بتسجيل في عدة مرات. يمكن أن يدرك وظيفة دفع الحساب لتسجيل الدخول عن بُعد ثم القفز إلى صفحة تسجيل الدخول. هنا نحتاج إلى شرح النقاط الرئيسية لهذه الوظيفة المطبقة التنبيه البسيطة. إذا كان هذا التنبيه سيظهر ، فيجب أن يكون قادرًا على إنهاء الطلب. ثم تقوم دالة طباعة الاستجابة بإخراج بيان مطالبة التنبيه ، لذلك لا يمكن أن يوجد بيان القفز المعلق. إذا كان هناك ، فلن يتم إصدار بيان المطالبة التنبيه ، لأن عمليتك لا تنتهي بشكل صحيح ولكن يتم إعادة توجيهها أو إعادة توجيهها إلى عمليات أخرى. سواء كان ذلك صحيحًا أم لا ، فسيتم إخراجه من إجراءات أخرى إلى الصفحة ، لذلك لن يظهر بيان طباعة الاستجابة الخاص بك. لذا فإن الطريقة الصحيحة هي: لم يتم إصدار طلب الاعتراض (ReturnFalse) ، ولا يزال الطلب هو الطلب الأصلي ولن يقفز. يمكن عرض معلومات طباعة الاستجابة مرة أخرى إلى الصفحة. بالنسبة للقفز إلى صفحة تسجيل الدخول ، يمكنك استخدام: out.println ("window.open ('"+arg0.getContextPath ()+"/new/login' ، '_ top') ؛") ؛ لتنفيذ يتم تنفيذ طلب إجراء في قسم من إخراج JS من خلال الاستجابة ، مشيرًا إلى صفحة تسجيل الدخول.
تم اعتبار الرمز أعلاه بشكل أساسي وظيفة تسجيل دخول مستخدم واحدة ، ولكن ستجد أن تشغيل طلب AJAX لا يشير إلى صفحة تسجيل الدخول عند تسجيل الدخول إلى الموقع البعيد ، ولا توجد معلومات سريعة. اسمحوا لي أن أشرح السبب أولاً ، لأن Ajax الخاص بك يقدم طلبًا غير متزامن ، ويتم مطابقة عنوان URL المطلوب أيضًا في Mapper المعالج ، لذلك سيتم اعتباره الطلب ناجحًا (رمز حالة الإرجاع 200). سيصبح عبارة JS المطبوعة في الاستجابة أعلاه الطلب الناجح في النجاح ، وقيمة الإرجاع. يمكنك محاولة التعليق على الجملة أعلاه: arg1.setStatus (arg1.sc_gateway_timeout) ؛ في هذا الوقت ، يجب تنفيذ بعض العمليات الأخرى. الأول هو العبارة arg1.setStatus (arg1.sc_gateway_timeout) ؛ وظيفتها هي تعيين رمز الحالة الذي تم إرجاعه عن طريق الاستجابة. تشير الإعدادات أعلاه إلى أنه سيتم إرجاع رمز الحالة 504 لتمثيل خطأ الطلب. في هذا الوقت ، لن يستجيب طلب AJAX في طريقة النجاح ، ولكنه سيستجيب لطريقة خطأ AJAX. لذلك ، تحتاج فقط إلى تنفيذ الطريقة المقابلة في خطأ AJAX ، على سبيل المثال:
$ .ajax ({url: 'new/msd2' ، النجاح: الدالة (a) {Alert (a) ؛} ، خطأ: الوظيفة (rs) {if (rs.Status == 504) {document.write (rs.ResponSetext) ؛}}}) ؛عندما يتم اعتراض طلب AJAX بسبب تسجيل الدخول عن بُعد ، قم بتعيين Arg1.setStatus (Arg1.sc_gateway_timeout) ؛ يمكن تغيير حالة إرجاع الطلب إلى 504. ثم تستجيب طريقة الخطأ. عندما يتم تحديد أن الحالة هي رمز الحالة الذي تقوم بتعيينه ، document.write (Rs.Responsetext) ؛ المسؤول هو عبارة JS المطبوعة إلى مكتب الاستقبال في المعترض. لكي يتم تنفيذ هذه العبارات ، وثيقة. write () ؛ تحتاج الطريقة إلى كتابة الرمز إلى DOM لجعلها سارية المفعول. في هذه المرحلة ، تم تنفيذ جميع الطلبات وتوقيع واحد لطلبات AJAX غير المتزامنة بشكل أساسي.
اترك هذه المقالة فقط لتسجيل الكود والأفكار ومبادئ العمليات الرئيسية
لخص
ما سبق هو كل شيء عن تنفيذ تسجيل الدخول الفردي في SPRINGMVC Interceptor ، وآمل أن يكون مفيدًا للجميع. إذا كانت هناك أي أوجه قصور ، فيرجى ترك رسالة لإشارةها. شكرا لك يا أصدقائك لدعمكم لهذا الموقع.