Sessionچیست؟

یک session به چه دردی میخورد؟

در حالت کلی مفهوم یک session را باید از روی حالات و وضعیت های مختلف وب اپلیکیشن در زمانی که یک یوزر با آن در ارتباط است، بررسی کرد. از نظر من یک session نمونه ای از کنش های متقابل یک یوزر با یک وب اپلیکیشن است اما تاکید بر این موضوع در اینجا نمیتواند کمک زیادی در فهم قضیه نماید. در حال حاضر برای یک web session بهتر است از این باب وارد شویم: ” session ساختاری از داده است که وب اپلیکیشن از آن برای نگهداری موقتی اطلاعات استفاده میکند. این اطلاعات موقتی فقط در زمانی که یوزر با وب اپلیکیشن در ارتباط است کارایی دارد و خصوصیات یوزر را بیان میکنند. برای مثال شما میتوانید نام یوزر را در session ذخیره کنید تا دیگر برای هر بار ارتباط با وب اپلیکیشن، نیازی به ارسال کوئری نباشد یا مثلا میتوانید در session، اطلاعات مربوط به ارتباط صفحات با یکدیگر را ذخیره نمایید (برای مثال بین صفحات مرتبط با پروسه پرداخت اینترنتی). از طرف دیگر میتوان session را به دید یک حافظه موقت دید که بسرعت قابل دسترسی است و به هر یوزری که قصد استفاده از اپلیکیشن را دارد، تخصیص داده میشود و در نهایت هنگام خروج یوزر از وب اپلیکیشن، از بین میرود. از دید کلی این تمام آن چیزی بود که ماهیت یک session را نشان میدهد اما اگر بخواهیم کمی ریزتر از session بدانیم، باید گفت که مکانیسم کاری و نحوه پیاده سازی آن در اپلیکیشن هم در مراحل بعدی نکات مهمی هستند که باید از آن ها سر در بیاوریم. داستان را ادامه میدهیم: این حافظه موقت میتواند بصورت یک فایل متنی در file system، در یک دیتابیس و یا بر روی حافظه داخلی برنامه ای که اپلیکیشن را اجرا میکند، وجود داشته باشد. دومین چیزی که باید در این باب بدانیم، ساختار یک session است.
ساختار یک session

Session یک ساختار داده ای بر مبنای زوج پارامتر ” کلید- مقدار (ارزش)” یا همان “key-value” بزبان دیگر است. این ساختار را میتوانید بصورت یک hash table تصور کنید که هر یوزر برای آن که بتواند دیتای خود را در آن قرار دهد، باید یک hash key بگیرد. در بحث session هم میتوان hash key را معادل session ID دانست. یعنی هر یوزری که بخواهد اطلاعات خود را در session ذخیره نماید، باید یک session ID داشته باشد. ساختار اطلاعاتی session شبیه شکل زیر است:

با توجه به شکل بالا، وقتی که شما میگویید “session من” منظورتان غیرمستقیما اشاره به همان اطلاعاتی دارد که داخل session وجود دارد. هر یوزری فقط میتواند به session یا session هایی که مربوط به خود است، دسترسی داشته باشد. Session میتواند هم بر روی سرور و هم بر روی کلاینت ذخیره شود. اگر بر روی کلاینت باشد، توسط مرورگر و عمدتا بصورت یک کوکی ذخیره میشود و اگر بر روی سرور باشد، session ID ها توسط سرور ایجاد و مدیریت خواهند شد. بنابراین اگر میلیون ها کاربر به سرور ارتباط داشته باشند، به ازای تک تک آن ها session id منحصر بفرد ایجاد و ذخیره میشود.خوب حالا میخواهم دقیقا بر روی session های ذخیره شده بر روی سرور زوم کنم:
یک session چگونه کار میکند؟

در این قسمت میخواهیم بگوییم که یوزرها چگونه به session هایشان دسترسی پیدا میکنند؟
در مورد یک اپلیکیشن تک کاربره مثل یک desktop application، فقط یک یوزر وجود دارد، در نتیجه فقط یک session وجود خواهد داشت بنابراین برای اپلیکیشن کار سختی نیست که بین یوزر و session اطلاعاتی او ارتباط برقرار کند. اما در مورد یک وب اپلیکیشن، یک سرور کلاینت های مختلفی را روبروی خود دارد. در این حالت سرور از کجا متوجه میشود که چه session ای متعلق به یوزری ست؟ این جا دقیقا همان نقطه ای است که نقش و اهمیت session id خود نمایی میکند.قانون کلی به این صورت است که شما به عنوان یک کلاینت، به سرور session id خود را تحویل میدهید و در مقابل، سرور در صورتی که اطلاعات متناظر با session id شما را درون دیتا استور session هایش پیدا کند، حق دسترسی به آن را به شما خواهد داد. ساختار session شبیه گاوصندوقی ست که دیتای ما درون آن قرار دارد و کلید این گاوصندوق، session id است. سرور اطلاعات session را فقط به یوزری نشان خواهد داد که session id صحیح را ارائه دهد. بنابراین همانطور که در بحث session hijacking هم تاکید داشتیم، اگر مهاجم به هر نحوی بتواند session id شما را بدست آورد، میتواند session شما را برباید.

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

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