نسل جدید مدیریت نشست در Spring Session – Spring MVC

مدت زمان زیادی است که مدیریت نشست، بخشی از Enterprise Java قرار گرفته و به گونه ای در آن حل شده است که ما پس زمینه ذهن خود، آن را به عنوان یک مشکل حل شده و کم رنگ در نظر گرفته ایم، و نوآوری بزرگی در این عرصه در حافظه اخیر خود نمی بینیم.

با این حال روند رو به رشد به سمت micro service و برنامه های کاربردی، در مقیاس افقی بر روی ابرهای محاسباتی مفروضاتی که بر اساس آن ها، در ۲۰ سال گذشته سرویس های مدیریت نشست طراحی و ساخته شده است، در معرض نقص و ایراد در طراحی قرار می دهد.

APIهای Spring Session که به تازگی توسط Enterprise Java تهیه شده است، برخی از محدودیت های رویکرد فعلی در مدیریت نشست ها را برطرف کرده است. ما به طور خلاصه مشکلاتی را که مدیریت های نشست فعلی دارند، مطرح کرده و سپس به جزئیات چگونگی حل هر یک از این مشکلات توسط Spring Session می پردازیم. سپس چگونگی پیاده سازی آن را در پروژه نشان خواهیم داد.

Spring Session بر روی سیستم مدیریت نشست جاوا نوآوری های جدیدی ایجاد کرده که باعث شده است تا به سادگی بتوان:

  • برنامه های کاربردی مستقر بر روی ابر و به صورت افقی مقیاس پذیر[۱] را نوشت.
  • ذخیره سازی اطلاعات نشست ها را به سیستم های ذخیره سازی تخصصی خارجی نشست، مانند Redis یا Apache Geode منتقل کرد، این سیستم ها اطلاعات را درون یک خوشه با کیفیت بالا و کاملا مستقل نگه داری می کنند.
  • هنگامی که کاربران در حال درخواست دادن بر روی WebSocket هستند، HttpSession زنده[۲] نگه داشته شوند.
  • از طریق پردازش درخواست غیر وب، مانند پردازش پیام از طریق JMS، اطلاعات نشست در دسترس قرار گیرد.
  • با پشتیبانی جلسات متعدد برای هر مرورگر، بتوان به یک نتیجه کاربر پسندتری رسید.
  • تبادل شناسه نشست بین کلاینت و سرور را کنترل کرد. برای این کار APIهای Restful ساده ای طراحی شده است که از طریق آن ها به جای کوکی، شناسه نشست از طریق هدر ارسال شود.

نکته مهم این است که ماژول Spring Session به فریم ورک Spring وابسته نیست، و بنابراین شما به راحتی می توانید آن را در پروژه هایی که از فریم ورک Spring استفاده نمی کنند، به کار بگیرید.

مشکلات استفاده از مدیریت نشست سنتی

در این قسمت مشکلاتی که در مدیریت نشست سنتی JavaEE وجود دارد و Spring Session به دنبال رفع آن ها برآمده نشان داده شده است.

ساخت یک برنامه مقیاس پذیر افقی و مستقر بر روی ابر

معماری های نرم افزاری مستقر در ابر فرض می کند که یک برنامه ی در حال اجرا می تواند با ایجاد نمونه های بیشتری از نرم افزار، بر روی یک مجموعه از ماشین های مجازی کوچک گسترش یابد. به عنوان مثال به سادگی می توان یک فایل .war را به Tomcat در حال اجرا در ابر Cloud Foundry و یا Heroku داد و سپس به در چند ثانیه، برنامه را به ۱۰۰نمونه و حافظه ۱GB برای هر نمونه گسترش داد. شما همچنین می توانید پیکربندی ابر را به گونه ای انجام دهید که به صورت خودکار تعداد نمونه های نرم افزار را بر اساس تقاضای کاربر افزایش و کاهش دهد.

بسیاری از سرویس دهنده نرم افزار، برای سادگی پیاده سازی و سرعت بالاتر، نشست های HTTP را در همان JVM قرار می دهند که کد برنامه در حال اجرا است. هنگامی که یک سرور برنامه جدید به خوشه سرورها می پیوندد و یا آن را ترک می کند، جلسات HTTP بر روی سرورهای باقیمانده مجددا متوازن می شوند. در یک محیط ابری الاستیک، که در آن صدها نمونه از برنامه های سروری در حال اجرا هستند و تعداد آنها به سرعت افزایش یا کاهش می یابد، چند مشکل در اجرا پیش خواهد آمد. از جمله:

  • ایجاد توازن مجدد نشست های HTTP می تواند باعث یک تنگنای عملکردی[۳] شود.
  • اندازه پشته بزرگ مورد نیاز برای ذخیره سازی تعداد زیادی از جلسات می تواند باعث شود gc[4] با ایجاد مکث، در عملکرد برنامه تاثیر منفی بگذارد.
  • معمولا TCP چندپخشی توسط زیرساخت ابر ممنوع است، اما غالبا توسط مدیران نشست برای تشخیص سرورهای برنامه ای که به خوشه می پیوندند و یا از آن جدا می شوند، استفاده می شود.

بنابراین، بهتر است برای ذخیره وضعیت نشست های HTTP از یک سرور خارج از JVM که کد برنامه در حال اجرا است استفاده کرد. به عنوان مثال ۱۰۰ نمونه از سرور Tomcat می تواند برای استفاده از ردیس برای ذخیره سازی نشست ها پیکربندی شوند، و با وجود اینکه تعداد نمونه های Tomcat کاهش یا افزایش می یابند، جلسات در ردیس بدون تاثیر باقی می مانند. همچنین به این علت که ردیس با C نوشته شده است، می تواند صدها گیگابایت و یا شاید حتی چند ترابایت رم را استفاده کند، چرا که در آنجا برای بازپس گرفتن حافظه، gc وجود ندارد.

برای سرور منبع باز[۵] مانند Tomcat راه حل دیگری برای پیدا کردن پیاده سازی های جایگزین مدیر نشست با استفاده از سرورهای خارجی مانند Redis و Memcached وجود دارد. هرچند فرایند پیکربندی می تواند پیچیده و مخصوص هر یک از سرورهای نرم افزاری باشد. برای محصولات منبع بسته[۶] مانند از WebSphere و WebLogic، یافتن پیاده سازی های جایگزین مدیران نشست، نه تنها دشوار، که اغلب غیر ممکن است.

Spring Session راه حلی برای پیکربندی مکان ذخیره سازی داده نشست ها فراهم می کند که محدودیت های Servlet را رعایت کرده و به APIهای خاص نرم افزار سرور برنامه کاربردی وابسته نباشد. این به این معنی است که Spring Session با تمام سرورهای برنامه کاربردی (Tomcat، Jetty، WebSphere، WebLogic، JBoss) که محدودیت های Servlet را پیاده سازی کرده باشند، کار می کند و به سادگی می توان پیکربندی را به یک شیوه در تمام سرورهای برنامه انجام داد. شما تنها باید سرور ذخیره سازی اطلاعات جلسات را متناسب با نیازهای خود انتخاب کنید. بنابراین Spring Session به عنوان یک ابزار برای مهاجرت برنامه های کاربردی از JavaEE سنتی به سمت ابر ایده آل است.

چندین حساب به ازای هر کاربر

فرض کنید که شما یک برنامه کاربردی تحت وب بر روی springmvc.ir ایجاد کرده اید که کاربران می توانند در آن چندین حساب ایجاد کنند. به عنوان مثال، کاربر saberi ممکن است دو حساب saberi@springmvc.ir وmohsen.saberi@springmvc.ir ایجاد کند. مانند دیگر برنامه های کاربردی وب جاوا، شما با استفاده از HttpSession، وضعیت جاری برنامه، مانند ورود کاربر به سیستم، را کنترل می کنید. بنابراین، هنگامی که کاربر بخواهد ازsaberi@springmvc.ir به mohsen.saberi@springmvc.ir تغییر حساب دهد، ابتدا باید از حساب جاری خارج و سپس وارد حساب بعدی شود.

با استفاده از Spring Session این امکان وجود دارد که کاربر بتواند بدون نیاز به خروج و ورود مجدد، بین حساب های خود جابجا شود.

بررسی امنیت چند سطحی

فرض کنید که در حال ایجاد یک برنامه وب با سطوح دسترسی پیچیده و سفارشی هستید، که در آن UI برنامه، خود را بر اساس نقش ها و مجوزهای اختصاص یافته به یک کاربر سازگار می کند.

به عنوان مثال، فرض کنید که نرم افزار دارای چهار سطح امنیتی عمومی، محرمانه، سری و بسیار سری باشد. هنگامی که یک کاربر وارد سیستم می شود، سیستم، بالاترین سطح امنیتی ممکن را برای کاربر استفاده می کند و تنها آن داده هایی را به کاربر نشان می دهد که در این سطح و یا سطوح زیرین آن باشند؛ بنابراین کاربری که سطح دسترسی عمومی دارد، خواهد توانست اسناد عمومی را ببینید، و یک کاربر است که سطح دسترسی سری دارد، می توانید اسناد عمومی، محرمانه و سری را مشاهده کند. برای این که رابط کاربر را مناسب تر درست کنیم، نرم افزار باید اجازه دهد تا کاربران پیش نمایشی از آنچه در یک سطح امنیتی پایین تر نمایش داده می شود را داشته باشد. به عنوان مثال یک کاربر در سطح بسیار سری می تواند نرم افزار را از حالت بسیار سری به حالت سری تغییر دهد تا ببینید که چگونه اطلاعات از نقطه نظر یک کاربر با مجوز سری مشاهده می شوند.

برنامه های کاربردی وب معمولی هویت کاربر و نقش های او را در نشست های HTTP ذخیره می کنند. اما از آنجایی که یک برنامه تحت وب تنها می تواند یک نشست را برای هر کاربری که وارد سایت می شود نگه دارد، بنابراین تنها در صورتی امکان سوئیچ کردن بین نقش ها، بدون نیاز به خارج شدن کاربر و سپس ورود مجدد او وجود دارد که جلسات متعددی را برای کاربران ایجاد کنیم.

با Spring Session شما به راحتی می توانید جلسات متعدد را برای هر کاربری که وارد سایت می شود ایجاد کنید به گونه ای که هر یک از این جلسات، کاملا از سایر جلسات مستقل باشند، بنابراین پیاده سازی قابلیت پیش نمایش کار ساده ای خواهد بود. به عنوان مثال کاربری که در حال حاضر در نقش بسیار سری وارد سایت شده است، می تواند برنامه را در حالت سری ببیند. تنها کافی است نشستی جدید با بالاترین نقش امنیتی سری به جای بسیار سری برای پیش نمایش ایجاد شود.

ماندن در حالت وارد شده در زمان استفاده از WebSocket

زمانی را تصور کنید که کاربران در برنامه تحت وب Springmvc.ir لاگین کرده و بخواهند با استفاده از یک کلاینت چت HTML5 و به کمک WebSocket با یکدیگر چت کنند. با توجه به مشخصات درخواست های سرولت که از WebSocket وارد می شود، در مورد زنده نگه داشتن نشست HTTP صحبتی به میان نمی آید. در نتیجه در حالی که کاربران در حال چت هستند، تایمر نشست HTTP با شمارش معکوس خود کم کم به زمان انقضا نزدیک می شود. در نهایت نشست HTTP را منقضی خواهد شد، اما از نقطه نظر کاربر، آن ها به طور فعال از برنامه استفاده می کردند. هنگامی که نشست HTTP منقضی شود، اتصال WebSocket نیز بسته خواهد شد. با Spring Session شما به راحتی می توانید مطمئن شوید که هر دو نوع درخواست  WebSocket و HTTP به طور منظم در زنده نگه داشتن نشست HTTP سهیم خواهند بود.

دسترسی به داده های نشست، برای درخواست غیر وبی

تصور کنید که نرم افزار شما دو راه برای دسترسی به خود در اختیار قرار می دهد: یکی با استفاده از یک REST APIهای بر روی HTTP، و دیگری از طریق پیام AMQP بر روی RabbitMQ. نخ[۷] هایی که درخواست را پردازش می کنند به HttpSession موجود در سرور دسترسی ندارد، و بنابراین شما مجبور به استفاده از یک راه حل سفارشی و از طریق مکانیسم خاصی برای به دست آوردن داده های موجود در نشست HTTP خواهید بود.

در صورتی که شناسی نشست را بدانید و از Spring Session استفاده کنید، شما می توانید از هر نخی در برنامه خود به اطلاعات نشست دسترسی داشته باشید. بنابراین Spring Session دارای یک API غنی تر نسبت به سرولت مدیر HTTP Session است، زیرا شما می توانید فقط با دانستن شناسه نشست، اطلاعات آن را بازیابی کنید. به عنوان مثال، درخواست های دریافتی می توانند هدر شناسه کاربری به همراه خود داشته باشند تا شما با کمک آن به طور مستقیم شناسه نشست را بازیابی کنید.

چگونه Spring Session کار می کند

حال که با مواردی که در آن نرم افزار مدیریت نشست سرور برنامه های HTTP عادی با مشکلاتی مواجه می شود آشنا شدید، اجازه دهید تا به راه حل هایی که Spring Session ارائه می دهد نگاهی بیاندازیم.

معماری Spring Session

هنگام پیاده سازی یک مدیر نشست باید به دو مشکلات کلیدی پاسخ داده شود. اول این که، چگونه یک نشست با دسترسی بالای خوشه ای ایجاد کنیم که بتواند داده ها را با قابلیت اعتماد و کارآمد ذخیره کند. دوم، چگونه تعیین کنیم که به عنوان مثال کدام نشست با کدام درخواست ورودی، چه درخواست HTTP، یا WebSocket، یا AMQP و یا هر پروتکل دیگر، تعلق دارد. اساسا سوال کلیدی این است: چگونه یک شناسه نشست بر روی پروتکلی که درخواست را منتقل می کند، حمل می شود؟

Spring Session فرض را بر این می گذارد که مشکل اول از طریق ذخیره سازی داده ها در یک خوشه مقیاس پذیر و با دسترسی بالا و توسط انواع نرم افزارها مانند Redis، GemFire، Apache Geode، و سایر نرم افزارهای مشابه، حل شده است و در نتیجه Spring Session باید یک مجموعه استاندارد اینترفیس ها را تعریف کرده که با پیاده سازی آن ها بتوان به اطلاعات ذخیره شده در این نرم افزارها دسترسی پیدا کرد. Spring Session اینترفیس های کلیدی زیر را تعریف می کند: Session, ExpiringSession و SessionRepository، که برای نرم افزارهای مدیر داده ای مختلفی پیاده سازی شده اند.

  • springframework.session.Session اینترفیسی است که قابلیت های اساسی یک نشست، مانند ذخیره و حذف صفات را تعریف میکند. این اینترفیس هیچ فرضی در مورد فن آوری زیرساخت ندارد و در نتیجه می توان از آن در یک سطح وسیع تری نسبت به سرولت HttpSession استفاده کرد.
  • springframework.session.ExpiringSession اینترفیس Session را با هدف افزودن ویژگی هایی برای تعیین اینکه آیا یک نشست به پایان رسیده است یا نه، گسترش داده است. RedisSession یک نمونه پیاده سازی این اینترفیس است.
  • springframework.session.SessionRepository متدهای ایجاد، ذخیره، حذف، و بازیابی یک نشست را تعریف کرده است. باید منطق ذخیره سازی یک نمونه از نشست در نرم افزارهای مدیر داده پیاده سازی شود. به عنوان مثال RedisOperationsSessionRepository یک پیاده سازی از این اینترفیس است که امکان ایجاد، ذخیره و حذف جلسات در ردیس را تدارک دیده است.

Spring Session فرض می کند که ارتباط بین یک درخواست و یک نمونه نشست، به پروتکل وابسته است؛ چرا که کلاینت و سرور نیاز دارند راهی برای انتقال شناسه نشست در طول چرخه درخواست/پاسخ فراهم آورند. به عنوان مثال اگر درخواست از طریق HTTP دریافت شده باشد، بنابراین یک نشست را می توان با کمک کوکی ها و یا هدرهای HTTP به درخواست مرتبط کرد. اگر HTTPS استفاده شود، با استفاده از SSL Session ID می توان ارتباط بین یک درخواست با یک نشست را بدست آورد. اگر JMS به کار رود، می توان از یک هدر JMS برای ذخیره ID نشست بین درخواست و پاسخ استفاده کرد.

برای پروتکل HTTP، Spring Session اینترفیسی به نام HttpSessionStrategy با دو پیاده سازی پیش فرض CookieHttpSessionStrategy و HeaderHttpSessionStrategy ایجاد کرده است. پیاده سازی اولی از کوکی ها برای ایجاد ارتباط بین درخواست و شناسه نشست استفاده می کند. پیاده سازی دوم نیز از یک هدر HTTP سفارشی این ارتباط را ایجاد می کند.

بخش بعد به جزئیات چگونگی عملکرد Spring Session بر روی HTTP تمرکز کرده است.

Spring Session بر روی HTTP

Spring Session بر روی HTTP به عنوان یک فیلتر سرولت استاندارد پیاده سازی شده است که باید به گونه ای تنظیم شود که تمام درخواست های برنامه وب را دریافت کند، و باید اولین فیلتر، در زنجیره فیلتر باشد. مسئولیت فیلتر Spring Session این است که اطمینان حاصل کند که هر کدی که در ادامه متد getSession() از javax.servlet.http.HttpServletRequest را فراخوانی کند، یک نمونه از Spring Session HttpSession را به جای HttpSession پیش فرض سرور دریافت خواهد کرد.

ساده ترین راه برای درک این موضوع، رجوع به کد منبع واقعی استفاده شده توسط Spring Session است. در ابتدا یک نگاه اجمالی به نقاط گسترش سرولت استاندارد[۸] خواهیم داشت. این نقاط برای پیاده سازی Spring Session استفاده می شوند.

در سال ۲۰۰۱ سرولت ۲٫۳ ابزار ServletRequestWrapper را معرفی کرد. Javadoc مربوطه می گوید که ServletRequestWrapper یک پیاده سازی مناسب از اینترفیس ServletRequest فراهم کرده است که می تواند توسط توسعه دهندگانی که تمایل به انطباق درخواست به یک سرولت دارند، به عنوان یک super class استفاده شود. نمونه کد زیر از Tomcat استخراج شده و نشان می دهد که چگونه ServletRequestWrapper پیاده سازی شده است.

 

علاوه بر این، سرولت ۲٫۳ کلاس HttpServletRequestWrapper را به عنوان یک زیر کلاس از ServletRequestWrapper تعریف کرده است و می تواند به سرعت به عنوان یک پیاده سازی سفارشی از HttpServletRequest مورد استفاده قرار گیرد. کد زیر از Tomcat استخراج شده و نشان می دهد چگونه کلاس HttpServletRequesWrapper تعریف شده است.

 

بنابراین این کلاس های wrapper این امکان را به وجود می آورند که کدی نوشته شود که HttpServletRequest را گسترش داده و متدهایی که یک HttpSession برمی گردانند را سربارگذاری کرده تا بتوانند مقداری را برگردانند که توسط یک مخزن داده ای خارجی دریافت شده است. نمونه کد زیر از پروژه Spring Session استخراج شده است.

 

 

Spring Session یک فیلتر با نام SessionRepositoryFilter تعریف کرده است که اینترفیس Servlet Filter را پیاده سازی می کند. بخش مهمی از کد فیلتر در زیر آمده است.

نکته کلیدی این بخش این است که Spring Session بر روی HTTP در واقع یک ServletFilter ساده است که با استفاده از ویژگی های استاندارد به ارائه ویژگی های خود می پردازد. بنابراین، شما می توانید Spring Session را بدون نیاز به تغییر به فایل های war اضافه کنید. برای این کار باید از javax.servlet.http.HttpSessionListener استفاده کنید. Spring Session 1.0 از HttpSessionListener پشتیبانی نمی کند. با این حال این اینترفیس به Spring Session 1.1 M1 اضافه شده است.

پیکربندی Spring Session

پیکربندی Spring Session یک فرایند چهار مرحله ای است.

  • تنظیم محل ذخیره داده ها که در Spring Session استفاده خواهد شد.
  • اضافه کردن فایل های jar به برنامه تحت وب
  • اضافه کردن فیلتر Spring Session به برنامه های تحت وب
  • اتصال Spring Session به برنامه ذخیره سازی داده ها

Spring Session به صورت پیش فرض از Redis پشتیبانی می کند.

دو روش رایج برای تکمیل مراحل پیکربندی Spring Session اشاره شده در بالا وجود دارد. راه اول این است که از Spring Boot برای پیکربندی خودکار Spring Session استفاده شود. راه دوم، پیکربندی Spring Session با تکمیل هر یک از مراحل به صورت دستی است.

وابستگی Spring Session می تواند به راحتی و با استفاده از یک مدیر وابستگی مانند Maven و یا Gradle به برنامه اضافه شود. در صورت استفاده از Maven و Spring Boot باید وابستگی زیر به pom.xml اضافه شود.

 

وابستگی spring-boot-starter-redis تضمین می کند که همه jarهای مورد نیاز برای کار با ردیس در نرم افزار گنجانده شده باشد، به طوری که آن ها را می توان با Spring Boot به طور خودکار پیکربندی کرد. وابستگی spring-session فایل jar مربوط به Spring Session  را به برنامه اضافه می کند.

پیکربندی فیلر Spring Session Servlet می تواند به صورت خودکار توسط Spring Boot و با استفاده از @EntableRedisHttpSession انجام پذیرد.

 

پیکربندی اتصال بین Spring Session و Redis می تواند با اضافه کردن تنظیمات زیر در فایل application.properties انجام شود.

 

Spring Boot زیرساخت گسترده ای را برای پیکربندی اتصال به ردیس فراهم می کند و هر روشی که برای اتصال به یک پایگاه داده Redis استفاده شود قابل قبول است.

به طور پیش فرض Spring Session از کوکی های HTTP برای ذخیره شناسه نشست استفاده می کند. با این حال شما می توانید Spring Session را به گونه ای پیکربندی کنید که از یک هدر سفارشی HTTP مانند x-auth-token: 0dc1f6e1-c7f1-41ac-8ce2-32b6b3e57aa3 استفاده کند. این حالت می تواند در هنگام ساخت برنامه هایی که از APIهای RESTful استفاده می کنند بسیار مفید باشد.

استفاده از Spring Session

هنگامی که Spring Session پیکربندی شد، شما می توانید با آن با استفاده از API سرولت استاندارد با آن ارتباط برقرار کنید. به عنوان مثال در قطعه کد زیر، یک سرولت که با استفاده از API سرولت استاندارد، به نشست دسترسی پیدا کرده است را نشان می دهد.

 

جلسات متعدد با هر مرورگر

Spring Session قادر است با استفاده از یک پارامتر نشست مستعار[۹] به نام _s جلسات متعددی را برای هر کاربر نگه دارد. به عنوان مثال اگر یک درخواست با آدرس http://springmvc.ir/doSomething?_s=0 برسد، Spring Session مقدار پارامتر _s را خوانده و از آن برای تعیین نشست پیش فرض مربوط به درخواست استفاده می کند.

اگر درخواستی با آدرس http://springmvc.ir/doSomething?_s=1 دریافت شود، Spring Session می داند که این درخواست برای نشست با نام مستعار ۱ است. اگر درخواست دریافت شده پارامتر _s نداشته باشد، به عنوان مثال http://springmvc.ir/doSomething، در این صورت Spring Session از نشست پیش فرض، یعنی ۰=s_ برای پاسخ به آن استفاده می کند.

برای ایجاد نشست جدید برای هر مرورگر، فقط باید javax.servlet.http.HttpServletRequest.getSession() را فراخوانی کرد. در این صورت Spring Session نشست درست را برمی گرداند و یا یک نشست جدید بر اساس مفاهیم سرولت استاندارد ایجاد می کند. جدول زیر، رفتار getSession() را برای آدرس های مختلف از یک پنجره مرورگر نشان داده است.

HTTP REQUEST URL Session Alias getSession() behavior
springmvc.ir/resource ۰ اگر نشستی با نام مستعار ۰ وجود داشته باشد آن را برگردانده و در غیر این صورت نشستی با این نام خواهد ساخت
springmvc.ir/resource?_s=1 ۱ اگر نشستی با نام مستعار ۱ وجود داشته باشد آن را برگردانده و در غیر این صورت نشستی با این نام خواهد ساخت
springmvc.ir/resource?_s=0 ۰ اگر نشستی با نام مستعار ۰ وجود داشته باشد آن را برگردانده و در غیر این صورت نشستی با این نام خواهد ساخت
springmvc.ir/resource?_s=abc abc اگر نشستی با نام مستعار abc وجود داشته باشد آن را برگردانده و در غیر این صورت نشستی با این نام خواهد ساخت

 

همانطور که جدول بالا نشان می دهد نام مستعار نشست حتما نباید یک عدد صحیح باشد، بلکه تنها باید از همه از نام های مستعار نشست دیگری که برای آن کاربر صادر شده است متفاوت باشد. با این حال نام مستعار نشست صحیح احتمالا ساده ترین مقادیر برای کار باشند. Spring Session اینترفیس HttpSessionManager را فراهم کرده و متدهایی را برای کار با نام های مستعار نشست ها درون آن قرار داده است.

برای بدست آوردن HttpSessionManager جاری، در HttpServletRequest صفتی با نام org.springframework.session.web.http.HttpSessionManager قرار داده شده است. مثال زیر چگونگی دسترسی به HttpSessionManager را همراه با متدهای کلیدی نشان داده است.

 

[۱] Horizontally Scalable

[۲] Live

[۳] Performance bottleneck

[۴] Garbage collection

[۵] Open source

[۶] Closed source

[۷] Thread

[۸] Standard Servlet Extension Points

[۹] Alias Parameter

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

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