• 0 رای - 0 میانگین
  • 1
  • 2
  • 3
  • 4
  • 5
مسئلهء اختلاف زمان سرور و کلاینت در ست کردن کوکی ها با عمر کوتاه
#1
دیروز و پریروز میخواستم به سیستم رجیستر و لاگین خودم امکان تنظیم زمان لاگین خودکار از سوی کاربر موقع لاگین رو اضافه کنم.
میخواستم امکان تعیین زمان لاگین کوتاه، مثلا درحد 10 دقیقه رو هم توش بذارم، چون از نظر امنیتی این میتونه مفید باشه.
بعد به فکرم رسید که زمانی که بعنوان تاریخ انقضای کوکی از سمت سرور به کلاینت میفرستیم، اونوقت اون کلاینت طبیعتا ممکنه با سرور اختلاف زمان داشته باشه (بعلت تفاوت منطقهء زمانی)، و اون کوکی با کدام زمان سروکار خواهد داشت و آیا ممکنه عمرش کوتاهتر یا طولانی تر از چیزی بشه که ما میخواستیم؟

خب اینو الان که دسترسی به اینترنت پیدا کردم روی هاست خودم تست کردم و دیدم که بله، چنین پدیده ای عملا بوجود میاد و میتونه مشکل ساز بشه.

من بعنوان مثال در سمت سرور یک کوکی ست کردم با تایم 5 دقیقه با این دستور:

کد پی‌اچ‌پی:
setcookie('time''1'time()+5*60'/'); 

اما جالب اینکه در مرورگر بنده اصلا هیچ کوکی ای ثبت نشد. علت میدونید چی بود؟ بخاطر اینکه زمان محلی سیستم بنده از زمان سرور بیش از 5 دقیقه جلو بود و عملا کوکی ای که سرور برای من میفرستاد هیچوقت ست نمیشد چون زمانش برای من در گذشته بحساب می آمد (ست کردن کوکی در زمان گذشته، حتی باعث پاک شدن کوکی موجود از قبل هم میشه).

بعد مثلا یک کوکی با تایم 20 دقیقه ست کردم در سمت سرور، اما در سمت کلاینت عمرش فقط 10 دقیقه بود، چون زمان سیستم محلی من حدود 10 دقیقه جلوتر از سرور بود.

حالا یوقتا هم هست ممکنه اصلا زمان کلاینت هم درست تنظیم نباشه. مثلا ممکنه تاریخش نادرست باشه. در اونطور موارد هم طبیعتا مشکل پیش میاد، اما فکر میکنم بعنوان برنامه نویس، شناسایی و حل اینطور موارد وظیفهء بدیهی و اولویت های اصلی ما نیست و شاید بتونیم ازش صرفنظر کنیم؛ اما شاید هم اگر بتونیم براحتی اینطور موارد رو حداقل شناسایی کنیم و به کاربر گوشزد کنیم بد نباشه؛ بخصوص از نظر امنیتی! مثلا اگر تاریخ سیستم کاربر یک ماه عقب تر باشه، و لاگین خودش رو 10 دقیقه ای تعیین کنه، اونوقت اختلاف بین یک ماه و 10 دقیقه برای امنیت میتونه فاجعه بار باشه! (البته از دید امنیتی، یک راه حل جایگزین یا مکمل برای اینطور موارد میتونه چک کردن عمر لاگین در سمت سرور هم باشه، ولی این به تنهایی نه همهء مشکلات غیرامنیتی رو هم حل میکنه و نه حتی برای امنیت لزوما در همهء شرایط و سناریوها کاملا بی عیب و نقص یا حتی قابل استفاده بنظر میاد).

خب پس ما با این مسئلهء اختلاف زمانی بین سرور و کلاینت چه کنیم بنظر شما؟
در اینکه باید شناسایی و حلش کنیم که شکی نیست بنظرم. اما میتونید تجربیات و راه حلهای مورد نظر خودتون رو بیان کنید. البته این تاپیک جنبهء آگاهی رسانی نسبت به این نکته رو هم داشت.

راستی اختلاف ساعت بین مناطق زمانی در جهان حداکثر تا 12 ساعت میتونه باشه دیگه؟

حداقل با JS باید یه کارهایی بکنیم دیگه.
من دنبال این نیستم که دیگه کمبودهای کلاینت و قصور کاربر رو هم گردن برنامه نویس بندازیم.
چند وقت پیش به این نتیجه رسیدم که دیگه باید حضور JS در کلاینت رو بعنوان یک پیشفرض برنامه نویسی بذاریم (مگر در شرایط خاص و اینکه خلافش نیاز باشه).

هرچند اگر JS هم نباشه، احتمالا بشه از روش دیگری مشکل در ست شدن و عمر کوکی ها رو تشخیص داد.
مثلا یه کوکی ست میکنیم با زمان چند ثانیه، بعد بوسیلهء تگ متا که امکان رفرش کردن صفحه بدون استفاده از جاوااسکریپت رو میده، اون صفحه رو که میتونه در یک iframe پنهان باشه، مجددا رفرش میکنیم، که نتیجتا باید در سمت سرور اون کوکی اگر در کلاینت ست شده باشه و موجود باشه دریافت بشه، اگر دریافت نشد یعنی مشکلی در ست کردن کوکی در سمت کلاینت داریم.

ولی خب شاید این راه حل دیگه لزومی نداشته باشه. چون اینقدر تعداد چنین کاربرانی و چنین احتمالی کم بنظر میاد که فکر میکنم میشه ازش صرفنظر کرد؛ مگر بازم در شرایط و سناریوهای خاص.

یه ایدهء دیگر هم میتونه این باشه که تاریخ انقضای کوکی رو در خود محتویات کوکی ذخیره کنیم.
بعدش عمر کوکی رو میتونیم مثلا یک سال یا اصلا هرچند سال بذاریم، ولی تاریخ انقضای کوکی که در خود کوکی هست در سمت سرور خونده میشه و بر اساس اون کار صورت میگیره (بر اساس زمان سرور).
البته این راهکار از دید اصول امنیت به هیچ وجه کافی نیست (ولی از هیچی بهتره)، چون کوکی اگر بیش از زمان تعیین شده روی سیستم کلاینت بمونه ممکنه اطلاعات حساسی مثل کلید لاگین و مشخصات کاربر توسط دیگرانی که به سیستم دسترسی پیدا میکنن مشاهده/سرقت بشه که میتونه مورد سوء استفاده برای دسترسی غیرمجاز به اکانت کاربر هم قرار بگیره، و خب تاریخی که در کوکی ذخیره کردیم هم میتونه توسط هکرها براحتی دستکاری بشه.

ما از نظر امنیتی میتونیم زمان انقضای کوکی لاگین رو در سمت سرور ذخیره کنیم و با هر درخواست چک کنیم اگر زمان انقضاش گذشته بود، اون رو باطل کنیم.
اما عمر کوکی لاگین در سمت کلاینت هم بهتره یا اصلا واجبه که درست ست بشه. چون اگر درست ست نشه، ممکنه کوکی اصلا ست نشه یا خیلی زود منقضی بشه، و یا ممکنه خیلی بیش از زمان مورد انتظار روی کلاینت باقی بمونه و به این شکل ریسک امنیتی هست که افراد دیگری محتویات اون رو که ممکنه از نظر امنیتی حساس و قابل سوء استفاده باشن مشاهده/سرقت کنن.
البته برای این هم میشه از الگوریتم های خاصی یا روشهای رمزنگاری استفاده کرد.
فعلا فقط میخوام جوانب و راه حلهای کلی این مسئله رو روشن کنم.
  پاسخ
تشکر شده توسط : nimaee
#2
کشف گردید که ظاهرا بنده در این زمینه اشتباهی کرده ام!

بنابراین این کپی پست اصلاحی و تکمیلی که در فروم برنامه نویس گذاشتم:

نقل قول:من الان چندتا تست دیگه انجام دادم دیدم در این مورد ظاهرا حق با شماست.
یعنی کوکی ها در سمت سرور بر اساس زمان GMT ارسال میشن به مرورگر، و مرورگر هم که بر اساس زمان سیستم زمان انقضای کوکی رو میسنجه (حالا روی هر منطقه ای که میخواد، درست یا غلط، تنظیم شده باشه).
اینطوری پس خوبه!
ولی مسئله ای که منو گمراه کرد اون تستی بود که انجام دادم.
و البته مسئلهء امکان اشتباه بودن زمان سیستم کلاینت به گمانم هنوز هم تاحدی وجود داره، مثل سیستم خودم که زمانش دقیق نبود.
درواقع من الان با سینک کردن زمان سیستم در ویندوز از طریق سرورهای زمان اینترنتی زمان سیستم رو دقیق کردم؛ ولی قبلش این داستان خاموش بود (یادم نیست بخاطر چی غیرفعالش کرده بودم).
شاید زیاد نمیشه بهش اعتبار کرد. سرور اولی (time.windows.com) که انگار کار نمیکرد زدم روی سرور دوم (time.nist.gov). یعنی میگم نکنه بخاطر تحریم بوده!
بعدشم حالا که فعالش کردم باید چک کنم ببینم دقتش تا چه حده. یعنی مثلا دیگه همیشه ساعت سیستم حتی چند دقیقه هم بهم نمیخوره؟
بعد مسئلهء دیگر اینکه بهرحال همینطور مثل من ممکنه سیستمهای دیگری هم در این حد چند دقیقه و اینها حداقل ساعتشون دقیق نباشه، که این روی کوکی های با عمر کوتاه تاثیر میذاره. یک مسئله هم سیستمهایی که به هر علتی ممکنه اصلا تاریخشون اشتباه باشه در اون موقعی که در سایت لاگین میشه. مثلا تازه اومده بالا و تنظیم نبوده و هنوزم وقت نکرده از اینترنت سینک کنه. بعضی سیستمها هست به هر علتی موقعی که میان بالا تاریخ سیستم غلطه.

ولی خب با اینکه شما گفتی و منم تست کردم دیدم درسته بخش اعظم مسئله به گمانم رفع شد!
البته با این وجود بد نیست اگر بازم احتیاط و فکری در این زمینه بکنیم.
  پاسخ
تشکر شده توسط :
#3
من خودم برای اینکار به دو روش عمل می کنم
۱- لاگین بلند مدت: اگر لاگین بلند مدت بود که طول زمان لاگین رو خیلی زیاد در نظر می گیرم و مدت زمانش رو از طریق سرور چک می کنم.
۲- لاگین کوتاه مدت: من برای این مورد از زمان استفاده نمی کنم و به اصطلاح فنی کوکی رو به صورت Session (نشست مرورگر ) ذخیره می کنم. به این ترتیب تا زمانی که صفحه بازه کوکی هم برقراره زمانی که صفحه بسته میشه کوکی هم دیگه نیست.
  پاسخ
تشکر شده توسط :
#4
(۱۳۹۲ آذر ۳۰, ۰۶:۱۷ ب.ظ)vejmad نوشته: کشف گردید که ظاهرا بنده در این زمینه اشتباهی کرده ام!

بنابراین این کپی پست اصلاحی و تکمیلی که در فروم برنامه نویس گذاشتم:

نقل قول:من الان چندتا تست دیگه انجام دادم دیدم در این مورد ظاهرا حق با شماست.
یعنی کوکی ها در سمت سرور بر اساس زمان GMT ارسال میشن به مرورگر، و مرورگر هم که بر اساس زمان سیستم زمان انقضای کوکی رو میسنجه (حالا روی هر منطقه ای که میخواد، درست یا غلط، تنظیم شده باشه).
اینطوری پس خوبه!
ولی مسئله ای که منو گمراه کرد اون تستی بود که انجام دادم.
و البته مسئلهء امکان اشتباه بودن زمان سیستم کلاینت به گمانم هنوز هم تاحدی وجود داره، مثل سیستم خودم که زمانش دقیق نبود.
درواقع من الان با سینک کردن زمان سیستم در ویندوز از طریق سرورهای زمان اینترنتی زمان سیستم رو دقیق کردم؛ ولی قبلش این داستان خاموش بود (یادم نیست بخاطر چی غیرفعالش کرده بودم).
شاید زیاد نمیشه بهش اعتبار کرد. سرور اولی (time.windows.com) که انگار کار نمیکرد زدم روی سرور دوم (time.nist.gov). یعنی میگم نکنه بخاطر تحریم بوده!
بعدشم حالا که فعالش کردم باید چک کنم ببینم دقتش تا چه حده. یعنی مثلا دیگه همیشه ساعت سیستم حتی چند دقیقه هم بهم نمیخوره؟
بعد مسئلهء دیگر اینکه بهرحال همینطور مثل من ممکنه سیستمهای دیگری هم در این حد چند دقیقه و اینها حداقل ساعتشون دقیق نباشه، که این روی کوکی های با عمر کوتاه تاثیر میذاره. یک مسئله هم سیستمهایی که به هر علتی ممکنه اصلا تاریخشون اشتباه باشه در اون موقعی که در سایت لاگین میشه. مثلا تازه اومده بالا و تنظیم نبوده و هنوزم وقت نکرده از اینترنت سینک کنه. بعضی سیستمها هست به هر علتی موقعی که میان بالا تاریخ سیستم غلطه.

ولی خب با اینکه شما گفتی و منم تست کردم دیدم درسته بخش اعظم مسئله به گمانم رفع شد!
البته با این وجود بد نیست اگر بازم احتیاط و فکری در این زمینه بکنیم.

خب اگر کاربر تیک زمانش رو فعال نکرد چی؟ یا اگر کامپیوتر در محیط اینترنت نبود و داخل شبکه داخلی کار می کرد چی؟
  پاسخ
تشکر شده توسط :
#5
(۱۳۹۲ آذر ۳۰, ۰۶:۲۷ ب.ظ)admin نوشته: لاگین کوتاه مدت: من برای این مورد از زمان استفاده نمی کنم و به اصطلاح فنی کوکی رو به صورت Session (نشست مرورگر ) ذخیره می کنم. به این ترتیب تا زمانی که صفحه بازه کوکی هم برقراره زمانی که صفحه بسته میشه کوکی هم دیگه نیست.
آره منم که همین کار رو کرده بودم.
ولی فکر کردم چون پروژم روی بحث امنیت خیلی جدی بوده، باید زمان های کوتاه انتخابی توسط کاربر رو هم اجازه بدم.
بهرحال مرورگر ممکنه برای زمان طولانی باز باشه کاربر یادش بره ببنده یا اصلا نخواد به اون زودی ببنده و در سایتهای دیگری همچنان کار داشته باشه.
ممکنه اصلا سیستم Hibernate بشه و بعدا که دوباره بالا میاد مرورگر به همون صورت باز باشه.
اگر یک گزینهء زمانهای کوتاه رو بذاریم، از نظر امنیت کاربردی بنظر میاد.
یعنی من موقع لاگین تعیین کنم فقط برای حداکثر 10 دقیقه، و بعد خیالم اینقدر از امنیت سیستم راحت باشه که نیاز نباشه به چیز دیگه ای فکر کنم و کار دیگه ای بکنم (البته برای محکم کاری کافی نیازه که زمان لاگین در سمت سرور هم چک بشه).

نقل قول: خب اگر کاربر تیک زمانش رو فعال نکرد چی؟
منظورت اون گزینهء sync time توی ویندوزه؟
فکر کنم بصورت پیشفرض فعاله. من خودم غیرفعال کرده بودم.
البته طبیعتا مثل منهم افراد دیگری هستن که همین کار رو کرده باشن به هر علتی.

نقل قول:یا اگر کامپیوتر در محیط اینترنت نبود و داخل شبکه داخلی کار می کرد چی؟
آره دیگه اینم یه سناریو هست.
همهء شبکه ها هم که time server و این حرفا ندارن و با هم sync نمیشن.
  پاسخ
تشکر شده توسط :
#6
برای لاگین کوتاه مدت:
یه مسئله ای که هست اینه که داخل این کوکی قراره چی ذخیره بشه.
قرار داخل این کوکی آی دی سشن ذخیره بشه؟ اگر آره که خود سشن زمان انقضا داره. اگر خیر قراره چه چیزی ذخیره بشه که جنبه امنیتی داشته باشه و چرا نباید توی سشن ذخیره بشه؟
  پاسخ
تشکر شده توسط :
#7
(۱۳۹۲ دى ۰۱, ۱۱:۵۸ ق.ظ)admin نوشته: یه مسئله ای که هست اینه که داخل این کوکی قراره چی ذخیره بشه.
مثلا کلید لاگین خودکار (یک رشتهء رندوم طولانی).
و بعضی چیزهای دیگه مثل مثلا یک آیدی عددی که کلید رکورد اکانت کاربر در دیتابیسه.

نقل قول:اگر آره که خود سشن زمان انقضا داره.
زمان انقضای سمت سرور منظورته؟
همون مکانیزم زباله روب سشن ها رو میگی؟
روی اون نمیشه حساب کرد.
اون داستان و هدفش تفاوت میکنه بنظرم.
  پاسخ
تشکر شده توسط :
#8
(۱۳۹۲ دى ۰۱, ۱۲:۰۲ ب.ظ)vejmad نوشته:
(۱۳۹۲ دى ۰۱, ۱۱:۵۸ ق.ظ)admin نوشته: یه مسئله ای که هست اینه که داخل این کوکی قراره چی ذخیره بشه.
مثلا کلید لاگین خودکار (یک رشتهء رندوم طولانی).
و بعضی چیزهای دیگه مثل مثلا یک آیدی عددی که کلید رکورد اکانت کاربر در دیتابیسه.

نقل قول:اگر آره که خود سشن زمان انقضا داره.
زمان انقضای سمت سرور منظورته؟
همون مکانیزم زباله روب سشن ها رو میگی؟
روی اون نمیشه حساب کرد.
اون داستان و هدفش تفاوت میکنه بنظرم.

خب کلید لاگین خودکار که برای لاگین های طولانی مدت استفاده میشه. آیدی کاربر هم که توی کوکی ذخیره بشه یا برامون ارزش نداره که تغییر پیدا کنه که داریم داخل کوکی ذخیره کنیم که در این صورت بحث امنیتی نداره.
منظور من بیشتر سشن روی دیتابیس هست. (حالا چرا مکانیزم زباله روب سشن ها مشکل داره؟ داز یه کرون اجرا میکنه و اطلاعات رو پاک می کنه).

یک مقدار سناریو مشخص نیست.
  پاسخ
تشکر شده توسط :
#9
(۱۳۹۲ دى ۰۱, ۱۰:۱۰ ب.ظ)admin نوشته: خب کلید لاگین خودکار که برای لاگین های طولانی مدت استفاده میشه.
مثل اینکه یادت رفته. قبلا هم گفته بودم. من مدتها پیش استفاده از سشن برای احراز هویت رو در پروژم کنار گذاشتم بخاطر ضعفها و محدودیت ها و مشکلاتی که داشت.
حتی برای لاگین کوتاه مدت هم از سشن استفاده نمیکنم، و لزومی هم نمیبینم.
خیلی وقت پیش سیستم احراز هویت من ترکیبی از هردوی سشن و کوکی+دیتابیس بود، ولی به مرور زمان متوجه شدم که این سیستم ترکیبی کار رو مدام پیچیده و غیرمنعطف میکنه و درمقابل ارزش و فایدهء چندانی هم نداره.
در سیستمهای ساده و نادقیق، سشن میتونه خوب باشه، ولی یک سیستمی که از نظر منطق و دقت و امنیت میخواد در سطح بالایی باشه باور کن باید آدم سیستم احراز هویتش رو خودش از صفر و بصورت کامل و دقیق و اصولی بنویسه. و برای این هم نمیشه راه دیگری رو رفت بغیر از کوکی+دیتابیس. اینطوری همه چیزش دست و تحت کنترل خودته.

نقل قول:آیدی کاربر هم که توی کوکی ذخیره بشه یا برامون ارزش نداره که تغییر پیدا کنه که داریم داخل کوکی ذخیره کنیم که در این صورت بحث امنیتی نداره.
از دید امنیت درحد بالا و اصولیش، حتی همون آیدی کاربر هم اهمیت امنیتی داره و بهتره حتی الامکان ازش محافظت بشه. آیدی کاربر که در تمام سیستمها پابلیک نیست. تازه اصلا بجای آیدی هم ترجیحا باید از یک رشتهء رندوم دیگری استفاده کرد. چون مثلا یک آیدی عددی که کلید رکورد کاربر در جدول اکانتها هست رو درنظر بگیر، این کلید خودش یک نوع نشت اطلاعاتی داره میده. مثلا از روی اون میشه فهمید یا کمک میکنه به اینکه بفهمی اون کاربر بعنوان چندمین کاربر در سیستم ثبت نام کرده (و قبل و بعد از چه کسانی) و شاید اینکه حول و حوش چه زمانی. حتی درمورد تعداد کاربران سیستم (یا حداقل تعداد اونا) هم میتونه اطلاعاتی بده. همینطور اگر آیدی مثلا عدد 1 باشه، طرف میتونه بفهمه که اون اکانت ادمینه!
حتما تاحالا چنین حرفایی نشنیدی، ولی در امنیت در سطح بالا و مسائل رمزنگاری و حمله های پیچیده و علمی، اینطور چیزها هم مطرح هستن و حتی الامکان باید جلوی هر نشت اطلاعاتی رو گرفت (هرچند جلوی نشت اطلاعات رو بطور کلی و مطمئنی گرفتن در تمام موارد عملا غیرممکن بنظر میرسه، ولی حداقل موارد درشت تر و راحتتر رو اگر میتونیم باید انجام بدیم از دید اصولیش).

نقل قول:منظور من بیشتر سشن روی دیتابیس هست.
آدم اگر بخواد سشن رو بریزه توی دیتابیس، همون بهتره که اصلا استفاده نکنه و سیستم کامل خودش رو جاش بذاره.
اون سشن با اون همه تنظیمات و چیزهای عجیب غریبش!!

البته من میگم فقط برای کارهای مهم و امنیتی ازش استفاده نمیکنم. برای چیزهایی مثل ذخیرهء هش کپچا و اینا استفاده میکنم. یعنی در کاربردهای کم اهمیت تر و موقتی.

نقل قول:حالا چرا مکانیزم زباله روب سشن ها مشکل داره؟ داز یه کرون اجرا میکنه و اطلاعات رو پاک می کنه.
خب باید الگوریتمش رو دقیق مطالعه کنیم، ولی درکل من خیلی وقت پیش بررسیش کرده بودم و بنظرم دقیقا اون چیزی نیست که ما انتظار داریم، و ضمنا نمیشه به کارکرد صحیحش براحتی اطمینان کرد. چون داستان و تنظیمات زیاد داره. مثلا اگر دایرکتوری سشن های برنامه اختصاصی خودش نباشه، و تنظیمات سشن هر درخواست دقیقا یکسان و درست ست نشده باشن، زباله روب هم اونطوری که فکر میکنی کار نمیکنه، مثلا ممکنه یک فایلی رو زودتر یا دیرتر از موعد حذف کنه. کلا سیستمش هم بر اساس تصادف هست تاجاییکه یادمه. یعنی مثلا بصورت رندوم در هر 10 درخواست اجرا میشه و فایلهای قدیمی رو پاک میکنه. البته این عدد رندوم قابل تنظیم هست. خب چیز رندوم چیزی نیست که برای امنیت خوشایند باشه. برای امنیت حتی الامکان باید یه چیزی قطعی باشه، نه شانسی.
بعدش مثلا فکر میکنم که زباله روب بر اساس زمان آخرین دسترسی کار میکنه. یعنی مثلا اگر قرار بوده سشن برای 20 دقیقه باشه، ولی در طول چند ساعت کاربر هر 10 دقیقه یک درخواست به سرور ارسال کرده، اونوقت بعد از گذشت چند ساعت، فایل سشن هنوز تر و تازه سرجای خودش میمونه! البته از این مطمئن نیستم، ولی بنظرم این شکلی بود، شاید هم نباشه، ولی میبینی که نمیشه بدون تحقیق و تست بهش اطمینان کرد. بخاطر همینه میگم بهتره آدم سیستم خودش رو درست کنه. چون بهرصورت شما وقتی بخوای سیستم قوی و کاملی درست کنی، بقدر کافی کار و مشکلات داری و داخل کردن سشن در این بین سود زیادی که نداره هیچ شاید پیچیدگی و مشکلات و احتمال غفلت رو هم زیاد کنه.
بعدم فکر کن آیا در رفرنس و داکیومنت های برنامه نویسی PHP چیزی در مورد این مسائل درونی و ظریف گفته شده و آیا اطمینانی هست که در نسخهء بعدی یکی از اینها تغییری نکنه؟
مسئلهء سشن همینطور چیزهاست. اینکه یک سیستم کلی هست که از همه نظر در سطح متوسطه (در بعضی زمینه ها، منجمله امنیت، حتی از متوسط هم پایین تر) و برای کاربردهای عمومی و معمولی، نه خیلی دقیق و حساس، طراحی شده.
خیلی هم تنظیمات و تشکیلات و داستان داره حتی بنده هم که یک بار کلی روش مطالعه و تست کردم الان همش یادم نیست و نمیتونم مطمئن باشم! موقع کار کردن با سشن باید خیلی حضور ذهن داشته باشی و حواست جمع باشه؛ همهء تنظیمات لازم رو باید دقیق در هر صفحه و برنامه انجام بدی. درسته تنظیمات زیاد باعث انعطاف میشه، ولی باعث پیچیدگی و افزایش احتمال خطای انسانی و باگ هم میشه؛ بخصوص درمورد چیزی که خودت درستش نکردی و خوب توی ذهنت نیست و بهش تسلط نداری و با وجود مطالعه و تست بازهم نمیتونی از این مطمئن باشی که هیچ مسئلهء دیگری نمیتونه درکار باشه و پیش بیاد.
  پاسخ
تشکر شده توسط :
#10
شما سشن خود php رو جالا به هر دلیلی قبول نداری. و میگی باید از صفر نوشت. ولی به هر حال همون کاری که داری انجام میدی یه جور سشن هست و مواردی که گفتم برای همون سیستم که اطلاعات رو داخل سرور ذخیره می کنه صدق می کنه. حالا این چیزی که شما نوشتی سیستم سشن خودتون هست.
در مورد آیدی کاربر من حرفات رو قبول دارم ولی اون سناریویی بود که شما دادی و گفتی مثلا آیدی کاربر رو توی کوکی بریزیم. اگر قرار بود آیدی کاربر رو توی کوکی بریزیم که دیگه خودش یه مشکل امنیتی بود و نباید سر امنیت زمان کوکی بحث کنیم. از نظر من چیزی که سطح امنیتی داره باید داخل سرور نگهداری بشه و یک آیدی رندم توی کوکی ذخیره بشه (همون قضیه سشن).
  پاسخ
تشکر شده توسط :


پرش به انجمن:


کاربران در حال بازدید این موضوع: 1 مهمان