HandlerExecutionChain و Interceptorها – Spring MVC

HandlerMapping برای تعیین مسیر اجرای درخواستی که یک کاربر آن را صادر کرده است به کار می رود. این کار می تواند به عنوان مثال بر اساس URL درخواستی صورت پذیرد. هنگامی که یک نگاشت مناسب پیدا شود، HandlerMapping یک نمونه از HandlerExecutionChain را ایجاد کرده و برمی گرداند. این شی دستورات لازم را در مورد چگونگی روال پردازش درخواست، به سرولت Dispatcher خواهد داد.

HandlerExecutionChain شامل تعدادی interceptor و دقیقا یک handler (یا کنترلر) است که در کنار هم تمام امکانات مورد نیاز برای دسترسی به منطق کاری شما و دیگر خدمات مانند احراز هویت، ورود به سیستم، و فیلتر کردن را به شما می دهد.

HandlerExecutionChain همیشه شامل یک کنترلر برای اجرای درخواست است (به عبارت دیگر، اجرای منطق مورد نظر). کنترلر می توانید از هر نوع باشد. تا زمانی که کنترلر قادر باشد یک درخواست را پردازش کند، فرضیات خاصی در مورد آن وجود ندارد. یک HandlerAdapter مناسب وجود دارد که می داند از کنترلر در HandlerExecutionChain استفاده کند. به طور پیش فرض، Spring دو نوع HandlerAdapter را استفاده می کند، یکی کنترلری که از اینترفیس Controller استفاده کرده باشد و دیگری کنترلری از نوع ThrowAwayController. انواع مختلف کنترلرها در بخش بعد توضیح داده خواهد شد.

علاوه بر آن، یک HandlerExecutionChain ممکن است شامل یک یا چند HandlerInterceptor باشد، که قادر هستند درخواست های ورودی را intercept کنند. interceptor به ویژه برای اقداماتی مانند ورود به سیستم، امنیت، و حسابرسی مناسب است.

روال کار یک interception به شکل زیر است:

  1. تابع preHandle(HttpServletRequest, HttpServletResponse, Object)، در تمام HandlerInterceptorهای موجود در زنجیره ای اجرا فراخوانی می شود. شیء Object در این جا همان کنترلر است. این فراخوانی این اجازه را می دهد که شما هر گونه منطق اجرایی را قبل از کنترلر واقعی انجام دهید. برای مثال، در اینجا شما می توانید بررسی کنید که آیا کاربر، مجاز به صدور این درخواست می باشد (این کار می تواند با استفاده از UserRoleAuthorizationInterceptor انجام پذیرد که در ادامه توضیح داده شده است). بر مبنای مقدار بازگشتی تابع، Spring در مورد ادامه پردازش درخواست تصمیم گیری خواهد کرد. در صورتی دریافت مقدار false، شی dispatcher فرض را بر این می گذارد که interceptor، خود به درخواست رسیدگی کرده است (برای مثال، هنگامی که بر اساس محدودیت های امنیتی، اجازه صدور درخواست از یک کاربر گرفته می شود). در چنین موردی Spring بلافاصله ادامه بررسی درخواست را متوقف خواهد کرد؛ به این معنی که، تمامی فراخوانی های ()preHandle که تاکنون انجام نشده اند، دیگر انجام نخواهند شد، همچنین خود کنترلر هم اجرا نخواهد شد. با این حال، تابع ()afterCompletion هر interceptor که پیش از آن با موفقیت اجرا شده باشد، در این لحظه اجرا خواهد شد.
  2. handler موجود در HandlerExecutionChain بازیابی شده و به دنبال یکHandlerAdapter مناسب می گردد. همه HandlerAdapters در دسترس (چه آنهایی که در WebApplicationContext ثبت شده اند و یا به صورت پیش فرض ارائه شده باشند) بررسی خواهد شد تا مشخص شود کدام یک از آنها این handler را پشتیبانی می کند (معمولا بر اساس کلاس handler این تصمیم گیری انجام می شود). تقریبا در تمام موارد به جز برخی شرایط پیچیده و شاید نادر، نیازی به نگرانی در مورد HandlerAdapter، نحوه پیاده سازی و طریقه کار کردن آن، وجود ندارد. روال پیش فرض Spring به خوبی کار می کند.
  3. گام بعدی اجرای واقعی خود handler است. در این قسمت، منطق واقعی برنامه شما اجرا خواهد شد؛ بعد از آماده سازی اولیه مانند متصل کردن داده ها به پارامترها، درخواست به لایه میانی ارسال می شود. بعد از آنکه اجرای درخواست تکمیل شد، باید یک نمونه از ModelAndView، حاوی داده های مورد نیاز JSP و یا، برای مثال، قالب Velocity آماده شده تا به کمک آن ها، یک صفحه HTML و یا PDF رندر شود.
  4. در مرحله بعد، همه interceptorها، با استفاده از postHandle(HttpServletRequest,HttpServletResponse, Object, ModelAndView)، دوباره فراخوانی خواهند شد. در اینجا شما می توانید ModelAndView بازگشتی را تغییر دهید. شاید نیاز باشد ویژگی هایی به آن اضافه و یا حتی حذف کنید. اینجا آخرین جای است که شما می توانید قبل از رندر کردن view بر روی اجرای منطق تاثیر بگذارید.
  5. پس از آن، view مشخص و رندر خواهد شد. در قسمت بعد در مورد چگونگی تعیین و رندر کردن view صحبت خواهیم کرد.
  6. آخرین مرحله شامل فراخوانی afterCompletion(HttpServletRequest,HttpServletResponse, Object, Exception) تمامی interceptorها خواهد بود. Object همان handler است که منطق مرتبط با این درخواست را اجرا کرد. اگر در طول تکمیل اجرای درخواست یک استثنا رخ داده باشد، در آن صورت نیز اجرا به این قسمت خواهد رسید.

WebContentInterceptor

Spring شامل برخی HandlerInterceptorها است که اغلب در برنامه های کاربردی وب مورد نیاز هستند. یکی از این ابزارها، WebContentInterceptor است که قابلیت تغییر آسان رفتار cache در یک برنامه تحت وب را ایجاد می کند. از جمله وظایف دیگر آن، محدود کردن متدهایی مانند GET، POST وPUT است که توسط برنامه کاربردی وب مورد نظر پشتیبانی می شود. پیکربندی این interceptor به صورت زیر انجام می شود (ابزار UserRoleAuthorizationInterceptor بعدا توضیح داده خواهد شد):

 

جدول زیر اعضاء موجود در این interceptor را نشان می دهد.

عضو داده ای توضیحات مقدار پیش فرض
cacheSeconds تعداد ثانیه مورد استفاده در headerهای content caching -۱ که درنتیجه، headerهای no caching تولید می شود
supportedMethods متدهای مورد تایید interceptor. اگر متد درخواست، مجاز نباشد ServletException ایجاد می شود GET و Post
requireSession اگر درخواستی بدون وجود یک session ارسال شود یک ServletException ایجاد می شود false
useCacheControlHeader آیا در زمان تولید content caching headers، از HTTP 1.1 Cache-Control استفاده شود true
useExpiresHeader آیا در زمان تولید content caching headers از HTTP 1.0 Expires استفاده شود true

 

UserRoleAuthorizationInterceptor

Spring یک interceptor ساده برای بررسی مجوزهای کاربر، در کنار مجموعه ای از نقش تعیین شده از طرف شما تهیه کرده است. اضافه کردن این interceptor به HandlerMapping به همان روشی انجام می شود که برای content interceptor عمل شد. UserRoleAuthorizationInterceptor خصیصه ای را با نام authorizedRoles ارائه کرده است که درون خود، آرایه ای از رشته را ذخیره می کند. این interceptor مستقیما به HttpServletRequest.isUserInRole(String) نمایندگی[۱] فراخوانی می دهد. هنگامی که کاربر درخواستی صادر کند که در هیچ یک از نقش تعیین شده در پیکربندی interceptor نباشد، یک HttpServletResponse.SC_FORBIDDEN، مربوط به کد وضعیت ۴۰۳، به سمت کاربر فرستاده می شود. در این لحظه می توان کاربر را با استفاده از، برای مثال، نگاشت خطا موجود در web.xml، به یک صفحه خطا مناسب منتقل کرد. شما همچنین می توانید یک زیرکلاس از این interceptor ایجاد کرده و تابع (…)handlerNotAuthorized را به شکلی مناسب تغییر دهید.

UsersRoleAuthorizationInterceptor می تواند در ترکیب با ویژگی JAAS نرم افزار سرور استفاده شود. به طور کلی، در شرایط عادی استفاده از UserRoleAuthorizationInterceptor به تنهایی کافی است. اما این interceptor نمی تواند یک راه حل قدرتمند امنیتی باشد. برای یک راه حل های امنیتی کامل تر، از جمله ویژگی های پیشرفته مانند single-sign-on، توصیه می شود از امنیتی Acegi موجود در Spring استفاده کنید.

HandlerInterceptorهای دیگر ارائه شده توسط Spring MVC

HandlerInterceptorهای دیگری که توسط Spring MVC ارائه شده اند بر روی دو موضوع مانایی و زبان های بین المللی تمرکز دارند:

  • OpenSessionInViewInterceptor و OpenPersistenceManagerInViewInterceptor: به ترتیب برای استفاده در Hibernate و JDO به کار می رود
  • LocaleChangeInterceptor: از این interceptor امکان تغییر زبان و مکان را، به صورت درجا، یک برنامه تحت وب فراهم می کند

[۱] Delegate

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *