SESSION یا $_GET ؟؟؟

[Metal Gear Solid]

سلام
من امروز برای اولین بار از سشن ها استفاده کردم. و این سوال برام پیش اومد که وقتی میشه مقادیری رو با استفاده از سشن ها از یک فرم به فرم دیگه انتقال داد چرا از متد GET یا POST استفاده کنیم ؟
کسی هست یه توضیح بده تفاوت اینها رو درست متوجه بشم :خجالت:

[امیـرحسین]

اطلاعات SESSION در حافظه و فایل ذخیره میشه و از داده‌های GET و POST پیچیده‌تر کار میکنه و بیشتر سرور رو به کار میگیره.

[Metal Gear Solid]

خب به نظر شما چه مواقع از سشن استفاده کنیم بهتره ؟

[skyline]

سلام
شما با متد post یا get اطلاعاتی رو به کلاینت یا سرور میفرستید . اگر قرار باشه همه اطلاعات بدین شکل ارسال بشه امنیتی نخواهد داشت .
session در اصل یک مخزن اطلاعات (فایل ) بر روی سرور است و فقط موقعیت (کلید ) این آرایه به کلاینت و از کلاینت به سرور ارسال میشه و بدلیل اینکه اصل اطلاعات ارسال نمیشه و در سرور قرار داره امنیت دادها بالا است و توسط آن کلید نمیتوان از سمت کلاینت به آن اطلاعات دسترسی داشت مگر اینکه برنامه سرور را طوری نوشته باشید که آن اطلاعات برای کلاینت ارسال شود .
در session میتوان داده ها را با انواع مختلف ذخیره نمود .
کلاینت و سرور با رد و بدل کردن این کلید باعث میشوند که موقعیت داده ها گم نشود . و این کلید وجه تمایز کلاینتها برای سرور است .
این کلید در حالتی که کوکی فعال باشد از آن برای ارسال کلید استفاده میکند و نیازی به ارسال دستی نیست .

موارد استفاده : اعتبار سنجی - ذخیره آخرین تنظیمات - ورود دائمی - انتقال داده ها به فرمهای مختلف بدون نیاز به ارسال اطلاعات و ...
اگر توضیح بیشتری لازم داشتید ذکر کنم .

[eshpilen]

سلام
من امروز برای اولین بار از سشن ها استفاده کردم. و این سوال برام پیش اومد که وقتی میشه مقادیری رو با استفاده از سشن ها از یک فرم به فرم دیگه انتقال داد چرا از متد GET یا POST استفاده کنیم ؟

چه مقادیری رو مثلا؟

[MMSHFE]

با سلام، دوست گرامي يكسري مواقع مجبور هستيم از GET_$ و POST_$ استفاده كنيم و اون هم موقعي هست كه ميخوايم يكسري موارد رو از كاربر دريافت كنيم. مثلاً يك فرم داشته باشيم يا ازطريق آدرس يكسري اطلاعات رو دريافت كنيم و براساس اونها محتوا و رفتار صفحه ما فرق كنه. از اونجا كه اطلاعات GET_$ در آدرس و اطلاعات POST_$ هم در سورس كد صفحه قابل مشاهده است، امنيت زيادي نداره اما اين كار ما رو انجام ميده. اما يكسري وقتها هم هست كه ميخوايم برخي اطلاعات رو بين صفحات وب سايتمون رد و بدل كنيم بدون اينكه كاربر مطلع بشه يا بتونه اونها رو تغيير بده. در چنين مواردي از SESSION_$ استفاده ميكنيم كه نه تنها در اختيار تمام صفحات وب سايتمون هست، بلكه چون روي سرور ذخيره ميشه و چيزي براي كاربر نميفرسته (مگه اينكه خودمون اين كار رو انجام بديم)، امنيت نسبتاً بالاتري داره. البته حتي اگه Session رو براي كاربر ارسال كنيم، باز هم نميتونه تغييرش بده مگه اينكه كدمون رو نا امن ساخته باشيم. مثلاً چنين دستوري داشته باشيم:


$_SESSION['login']=$_GET['login'];

برخي از كاربران تازه كار چنين اشتباهاتي رو انجام ميدن. حالا كافيه يك بازديدكننده به انتهاي آدرس سايتمون login=true? رو اضافه كنه تا مقدار متغير Session به نام login بشه true و بتونه به بخشهاي مخصوص كاربران سايت دسترسي داشته باشه. البته اين موردي كه گفتم مربوط ميشه به مباحث امنيتي ولي در كل وظيفه GET_$ و POST_$ و SESSION_$ رو اميدوارم خوب توضيح داده باشم.
موفق باشيد.

[Metal Gear Solid]

@ eshpilen :
من فقط یه مقداری رو جهت تست انتقال دادم اما اگر یکم ریز باشیم میشه حتی مقادیر GET رو که درون سایت خودمون هستن هم از این طریق ارسال کرد.
مثلاً تصور کنید برای ویرایش مشخصات یک کاربر نیاز به UserID داریم که از طریق یک دستور MySQL این آیدی رو میگیریم. وقتی بخوایم لینکی برای ویرایش قرار بدیم باید بنویسیم

print " <a href="Edituser.php?uid=$QueryRow[userid]"> Edit User </a>";
خب میشه به جای اینکه اون uid رو توی آدرس لینک قرار بدیم اینطوری بنویسیم.

$_SESSION['uid_to_edit']=$QueryRow['userid'];
print "<a href="Edituser.php" > Edit User </a>";

وقتی کاربر روی لینک کلیک میکنه و به صفحه ی بعد میره. درسته uid توی آدرس نیست اما خب توی سشن هست و صفحه ی بعد با گرفتن مقدار سشن میتونه آیدی کاربر رو بگیره و اقدام به ویرایش کاربر کنیم.
به نظر شما این کار با بالایی چه فرقی داره ؟ جز اینکه امنیت بالاتری داره ؟ من زیاد با htaccess کار نکردم اما این دستور آدرس رو هم کم میکنه و یه جورایی کار htaccess رو هم انجام میده!


@ MMSHFE : آقا دست شما درد نکنه توضیح کاملی بود متوجه شدم. روشی که بالا گفتم نه در تمامی موارد اما گاهی اوقات میشه به جای GET یا POST هم استفاده بشه. به نظر من ...

[MMSHFE]

ضمن سلام مجدد، با شما موافقم. البته فقط در مواردي كه بخوايم يكسري اطلاعات رو از صفحه اي به صفحه ديگه بفرستيم كه در چنين مواردي، امنيت Session بالاتر هست و كلاً هدف Session هم همينه. اما در ساير موارد مثل دريافت اطلاعات از كاربر يا Bookmarkكردن صفحات بايد از همون روشهاي POST و GET استفاده كنيم.
موفق باشيد.

[eshpilen]

@ eshpilen :
من فقط یه مقداری رو جهت تست انتقال دادم اما اگر یکم ریز باشیم میشه حتی مقادیر GET رو که درون سایت خودمون هستن هم از این طریق ارسال کرد.
مثلاً تصور کنید برای ویرایش مشخصات یک کاربر نیاز به UserID داریم که از طریق یک دستور MySQL این آیدی رو میگیریم. وقتی بخوایم لینکی برای ویرایش قرار بدیم باید بنویسیم

print " <a href="Edituser.php?uid=$QueryRow[userid]"> Edit User </a>";
خب میشه به جای اینکه اون uid رو توی آدرس لینک قرار بدیم اینطوری بنویسیم.

$_SESSION['uid_to_edit']=$QueryRow['userid'];
print "<a href="Edituser.php" > Edit User </a>";

وقتی کاربر روی لینک کلیک میکنه و به صفحه ی بعد میره. درسته uid توی آدرس نیست اما خب توی سشن هست و صفحه ی بعد با گرفتن مقدار سشن میتونه آیدی کاربر رو بگیره و اقدام به ویرایش کاربر کنیم.
به نظر شما این کار با بالایی چه فرقی داره ؟ جز اینکه امنیت بالاتری داره ؟ من زیاد با htaccess کار نکردم اما این دستور آدرس رو هم کم میکنه و یه جورایی کار htaccess رو هم انجام میده!


میگم بجای uid_to_edit اسمش رو بذار userid. مگر uid_to_edit همون userid مربوط به کاربری که درحال حاضر لاگین هست نیست؟
و اما در این مورد خاص شاید بشه به این شکل که شما میگی برنامه رو ساده و امن کرد بدون اینکه به پارامترهای دیگه خدشهء چندانی وارد بشه. اما در خیلی موارد اینطور نیست. مثلا فرض کن طرف مدیر یا ادمین سایت هست و بنابراین اختیارات کامل داره و نیاز به مدیریت سایت و دستکاری اطلاعات کاربران هم احتمالا خیلی وقتا پیش میاد. در این موقع اگر صفحهء مورد نظر از طریق پارامترهای URL کاربر مورد نظر خودش رو دریافت بکنه میتونه مفید باشه و تعداد فایلها و پیچیدگی برنامه رو کاهش بده؛ یعنی انعطاف بالا میره. اگر پارامتر URL رو نداشته باشیم برنامه چطور میخواد بفهمه که ادمین قصد ویرایش اطلاعات (مثلا اصلاح یک امضای غیرمجاز) کدوم کاربر رو داره؟ بالاخره باید یه مکانیزم و فایل کم و بیش مشابهی براش گذاشت، یا اینکه همون یکی رو برای تمام این کارها به یک صورت استفاده کنیم.
یا مثلا موقعی که پروفایل کاربران نمایش داده میشه مثلا آدرس به اینصورت هست: profile.php?uid=126738
در این مورد راه دیگری آیا داریم؟
احتمالا یکسری موارد دیگه مثل خوانایی و اطلاعات مفید موجود در آدرس و کمک به بعضی چیزها در موقع تست و توسعه هم از مزایای روش پارامتری باشه. واسه منکه این چیزا خیلی وقتا مفید بوده. هم بعنوان کاربر و هم بعنوان برنامه نویس. مثلا چند بار شده توی سایتی یک مقاله ای رو گم کرده بودم و حتی گاهی مشکل فنی از خود سایت بوده، اما تونستم با حدس زدن و تغییر دادن پارامترهای آدرس مشکل رو حل کنم و به محتوای مورد نظرم دسترسی پیدا کنم. اگر مشخصات بصورت پارامتری نبودن این کار اونقدری سخت تر میشد که آدم اصلا دنبالش نمیرفت. گاهی هم شاید اصلا غیرممکن بشه.
شما بعنوان یه برنامه نویس یا برای مدیریت سایت و کشف و رفع اشکالات هم احتمالا بعضی وقتا این روش بهتون کمک میکنه. خوبی تنظیمات موجود در آدرس اینه که خیلی واضح و دائما در معرض دید و قابل ویرایش ساده و سریع هست و این میتونه برای سرعت و راحتی بعضی عملیات تست و توسعه و نظارت بر بعضی مسائل مفید باشه.
بطور کلی در موارد مشابهی که اهمیت امنیتی ندارن استفاده از پارامترهای آدرس معمولا بهترین گزینه برای اینطور کارها هست. این بطور مثال برای موتورهای جستجو هم میتونه خیلی مفید باشه. برای امکان بوکمارک کردن هم که مسلما لازمه. البته از روش POST هم بعضی جاها استفاده میشه و روش مناسبتر برای انجام بعضی عملیات هست.
یه نکته و اصولی که خیلی افراد نمیدونن اینه که جاهایی که فراخوانی مجدد یک آدرس، هربار تغییری رو در وضعیت سرور ایجاد میکنه استفاده از متد POST اصولی هست و متد GET استاندارد نیست. بطور مثال موقعی که فراخوانی یک آدرس هربار موجب درج یک رکورد در دیتابیس میشه نباید درخواست HTTP از طریق متد GET ارسال بشه (البته میشه در یک صفحهء POST پارامترهای URL رو هم داشت - در این حالت متد صفحه بازم POST هست). بخاطر همین هست که وقتی میخواید صفحه ای رو که قبلا با متد POST ارسال شده رفرش کنید مرورگر پیام میده که با این کار اطلاعات POST شده مجددا ارسال میشن و تایید میخواد، ولی درمورد صفحه های عادی (متد Get) اینطور نیست. چون متد POST میتونه Idempotent (http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Idempotent_methods_and _web_applications) نباشه.
البته من خودم فکر میکنم این اصول رو خیلی وقتا رعایت نکردم؛ اما فقط بخاطر راحتی و سرعت در برنامه نویسی و تست و توسعه و اینکه برنامه هام شخصی و کوچک و اکثرا درحد آزمایش و نمونهء اولیه بودن.
خب فکر میکنم این مسئله ای که گفتم درمورد ذخیرهء اطلاعات در سشن هم صادق باشه. یعنی اگر فراخوانی مجدد صفحه هربار باعث ایجاد تغییر در سمت سرور میشه، باید از متد POST در سمت کلاینت استفاده کنید گرچه اطلاعات شما در سشن ذخیره شده باشن. البته منظور از این گفته این نیست که باید اطلاعات اصلی و امنیتی خودتون رو به سمت کلاینت انتقال بدید و با متد POST ارسال کنید، فقط داریم میگیم متدی که درخواست از سمت کلاینت باهاش ارسال میشه باید POST باشه.