ایجاد امنیت کاربر لاگین کرده

[idocsidocs]

بنظرتون هر بار که اسکریپت لود می شه باید لاگین بودن کاربر رو چک کنیم یا فقط موقع ورود به سایت چک کنیم کافیه؟

[Veteran]

باید چک بشه ! که لاگین کرده یا نه ! مثلا شما فرض کن لاگین کرده رفته به قسمت مدیریت.توی مدیریت هم باید چک بشه ! وگرنه اگر بخوایم توی همه صفحات چک نکنیم به مشکل بر میخوریم.
وفتی لاگین کرد یک سشن ایجاد بشه و در تمامی صفحات اون سشن چک بشه

[mtchabok]

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

[idocsidocs]

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

[mamali-mohammad]

فرض کنید شما یه مدیر رو حذف کردید، ولی چون مدیر بر اساس سسشن ها لاگین به حساب می یاد، می تونه توی سایت باقی بمونه. این می شه یه ضعف برای سیستم.

بعد از چک کردن سشن کافیه بررسی کنی username گزینه active برابر با YES هست یا نه
اگه yes باشه که هیچ
اگه no باشه یعنی حذف شده cookie رو حذف کن

[mtchabok]

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

[idocsidocs]

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

مسئله دیگه در مورد لاگین همزمان چند نفر هست، برای این مورد باید چیکار کرد؟

[siavashsay]

پس توی هر بار اجرای اسکریپت حتما باید کلمه کاربری (ممکنه مدیر کاربر رو کلا حذف کنه) و وضعیت کاربری رو از دیتابیس چک کرد، درسته؟

مسئله دیگه در مورد لاگین همزمان چند نفر هست، برای این مورد باید چیکار کرد؟
دوست عزیز !
نمیدونم - جسارت نباشه ! قصد توهین هم ندارم ! اما میشه بگید سطح معلوماتتون از PHP چقدر هست تا دوستان راهنمایی کلی بکنن !
شما در موقع لاگین کردن ( چه مدیر - چه کاربر ) باید مقدار username رو چک کنید ! اگر مقداری داخل دیتابیس وجود داشت و با رمز عبور و اطلاعات کاربری اون فرد همخوانی داشت شما مجوز ورود اون شخص رو با یک Session به نام همون فرد ( یعنی برابر با Username اون ) ایجاد کرده و در بقیه صفحات ازون استفاده میکنید !
حالا میخواد هر تعداد کاربر باهم لاگین کنن ! فرقی نمیکنه ! هرکسی شناسنامه خودشو داره و با اون تردد میکنه !
از طرفی شما میگین تداخل و یا همزمان ! خوب کاربر ها که قرار نیست username هاشون یکی باشه !
این مورد ( لاگین کردن ) کوچک ترین قسمت یک برنامه نویسی هست !
اگر اطلاعی در این مورد نداشته باشید پس راه خیلی درازی رو دارید !
چون مباحث اصلی امنیت هنوز واستون رو نشده !
موفق باشید !

[idocsidocs]

شما در موقع لاگین کردن ( چه مدیر - چه کاربر ) باید مقدار username رو چک کنید !موضوع تاپیک امنیت برای کاربران لاگین کرده هست ولی این کار که شما می گید موقع لاگین انجام می شه!

چون مباحث اصلی امنیت هنوز واستون رو نشده !بقیه موارد بماند تا سایر دوستان پاسخ سوالات قبلی رو بدن و از بحث منحرف نشیم ............

[mtchabok]

پس توی هر بار اجرای اسکریپت حتما باید کلمه کاربری (ممکنه مدیر کاربر رو کلا حذف کنه) و وضعیت کاربری رو از دیتابیس چک کرد، درسته؟

مسئله دیگه در مورد لاگین همزمان چند نفر هست، برای این مورد باید چیکار کرد؟

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

در مورد لاگین همزمان متوجه نشدم منظورتون رو ؟

[siavashsay]

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

بقیه موارد بماند تا سایر دوستان پاسخ سوالات قبلی رو بدن و از بحث منحرف نشیم ............ انشالله که موفق باشید :قهقهه::قهقهه:

[idocsidocs]

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

در مورد لاگین همزمان متوجه نشدم منظورتون رو ؟
منظورم اینه که چند نفر با هم وارد یک حساب کاربری بشن

باید اجازه چنین کاری داد؟

امنیت رو باید قبل از لاگین هم مورد نظر قرار بدین ! نه اینکه بعد از لاگین یهو به فکر امنیت باشین
سوال من در مورد بعد از لاگین کاربرها هست. اگر در این مورد توضیحی دارید بفرمایید.............

[siavashsay]

سوال من در مورد بعد از لاگین کاربرها هست. اگر در این مورد توضیحی دارید بفرمایید.............دوست عزیز چرا متوجه نمیشید !
امنیت مثل یک رشتس که باید از اول شروع کنید !
شما در زمان لاگین باید سشن هاتون رو امن کنید ! یک سری متغیر رو در موقع لاگین ثبت کنید و بعداز لاگین اونا رو مورد بررسی قرار بدید !
مثلا IP ! موقع ورود فرد باید IP فرد گرفته شه و در همه صفحات سایت چک بشه که IP موجود با IP که در موقع ورود ثبت شده یکی هست یا نه ! اگر نبود یعنی کاربر وثلا VPN یا چیزی رو فعال کرده ( البته اگر خوشبین باشید ) در غیر اینصورت یعنی فرد دیگه ای به اطلاعات یک کاربر دسترسی و با User اون لاگین کرده ! اونجاس که باید دستور logout رو صادر کنید !
البته IP به تنهایی موثر نیست ! شما میتونید یک سری متغیر مربوط به سیستم کاربر رو مثل مشخصات Brower + IP + Random String و یک سری چیزهای دیگه رو مخلوط و HASH کنید و یک رشته به دست بیارید !
مثلا مخلوط اینها به صورت HASH میشه : 54rfgxcv54626486dfgdfxcxcvr5fdg
حالا همین کد رو باید توی هر صفحه چک کنید ببینید با رشته زمان ورود یکی هست یا نه ! اگر نبود logout
البته مسایل دیگه ای هم هست که این فقط یک نمونش بود !

[mtchabok]

منظورم اینه که چند نفر با هم وارد یک حساب کاربری بشن

باید اجازه چنین کاری داد؟
خوب بر میگرده به پروژتون
مثلا در برخی بازیها هست که اجازه دسترسی چند نفر به یه اکانت رو میدن

[mamali-mohammad]

دوست عزیز ، بحث شما مگه این نیست که کاربر وارد میشه
اگه شما حذفش کردی ، چون هنوز کوکی داره میتونه در سایت بمونه
شما میخوای اگه کاربر رو حذف کردی ، کاربر وارد شد نتونه از امکانات استفاده کنه و کوکی اتوماتیک پاک بشه
درسته ؟

[idocsidocs]

مثلا در برخی بازیها هست که اجازه دسترسی چند نفر به یه اکانت رو میدن برای مدیر وب سایتها چطور؟ باید این اجازه رو داد؟

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


البته مسایل دیگه ای هم هست که این فقط یک نمونش بود ! این مطاطلبی که گفتید جدید نبودن! مطالب بعدی هم فکر نکنم جدید باشن!

[eshpilen]

بآره درسته. اگر بعد از لاگین کاربر، حساب کاربریش رو حذف کردیم باید با هر بار اجرای اسکریپت دیتابیس رو چک کنیم تا متوجه تغییرات بشیم.

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

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

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

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

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

[Unique]

من هم با eshpilen موافق هستم که برای اینجور کارها نمیخواد زیاد مته به خشخاش بگذاریم و دو یا سه تا query ساده را بخوایم دور بزنیم ! اما همیشه میشه یکسری اطلاعات را cache کرد ! میتونید یک پوشه برای Login ها درست کنید و وقتی کاربری احراز هویت میشه از طریق cookie مرتبط فایل لاگین تشکیل بدیم و حالا اطلاعات مورد نظر را توی این فایل بریزین اعم از هر مقداری که نمیخواین توی هر بار درخواست توسط برنامه database هم چک بشه ! مثل نام و نام خانوادگی و دسترسی و آخرین باری که کاربر درخواست داده (برای Auto Logout در زمان مناسب) فرمت هم میتونه هر چیزی باشه ! sqlite یا xml یا ini حالا هر طور راحتین ! وقتی کاربر را میخواین برای دفعه دوم احراز هویت کنین اول میایم cookie مربوط به login را با فایل ها نظیر میکنیم اگه فایل پیدا شد که مقدار ها را میخونیم یا احراز هویت میشه و همه چیز Ok هست یا باید autologout بشه و فایل پاک بشه اما مشکل شما اینجا اینه که مثلا کاربر را میخوایم غیر فعال کنیم یا دسترسیش را محدود کنیم یا هر کاری که در login بودنش تاثیر میگذاره ! از اونجا که این موضوع کم پیش میاد اگه من باشم میام برای اون عملیات فایل login را پاک میکنم و کاربر اتوماتیک logout میشه توی درخواست بعدی و من هم هیچ عملیاتی با database انجام نمیدم اینطوری ! فقط باید فایل ها را در مقابل درخواست ها با htaccess. محافظت کنین.

اما باز هم میگم من از این تیپ کار ها تا وقتی مجبور نشم استفاده نمیکنم و ماژول اصلی login را بر اساس همون database پیاده کردم ، مگه اینکه سرور ضعیف باشه یا تعداد کاربران آنلاین چند صد یا هزار نفر باشه که غیر از یک پروژه دیگه نداشتم .!

[idocsidocs]

شما که بهرحال نیاز داری اینقدر با دیتابیس ارتباط داشته باشی، خب اصلا سشن رو بنداز دور و بجاش از دیتابیس استفاده کن! البته در بیشتر مواردی که ممکنه.
من برای سرورهای اشتراکی سسشن ها رو توی دیتا بیس ذخیره می کنم.

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

بغیر از اطلاعات لاگین، مجوزهای دسترسی کاربرها هم هستن که ممکنه یه آرایه بزرگ باشه و ذخیره اون توی سسشن حجم اطلاعات ذخیره شده توی سسشن رو بالا ببره.

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

البته بنظرم بهتره با ajax هر 60 ثانیه وضعیت لاگین بودن کاربرها رو توی دیتابیس درج کنیم و اگر کاربر از طریق صفحات دیگه logout کرده بود بقیه صفحات رو هم logout کنیم. در این مورد چه نظری دارید؟


اما باز هم میگم من از این تیپ کار ها تا وقتی مجبور نشم استفاده نمیکنم و ماژول اصلی login را بر اساس همون database پیاده کردم ، مگه اینکه سرور ضعیف باشه یا تعداد کاربران آنلاین چند صد یا هزار نفر باشه که غیر از یک پروژه دیگه نداشتم .! توی بازدیدهای بالا (چند هزار نفر) برای سرعت و امنیت بیشتر بهتره از فایل استفاده کنیم یا از دیتابیس؟

[engmmrj]

صلا سشن رو بنداز دور و بجاش از دیتابیس استفاده کن
میشه یه نمونه کد بزارین تا بفهمیم چگونه باید این کارو انجام بدیم

[eshpilen]

میشه یه نمونه کد بزارین تا بفهمیم چگونه باید این کارو انجام بدیم
خب الان این سیستم رجیستر و لاگین بنده: http://www.hamidreza-mz.tk/?p=887
درش از سشن برای احراز هویت استفاده نکردم.
از سشن فقط برای ذخیره هش کپچای فرم ثبت نام استفاده کردم؛ مورد دیگه ای هم یادم نمیاد.
id رکورد اکانت کاربر و کلید لاگینش رو در یک کوکی ذخیره کردم که در هر درخواست با دیتابیس چک میشه.

[idocsidocs]

خب الان این سیستم رجیستر و لاگین بنده: http://www.hamidreza-mz.tk/?p=887
درش از سشن برای احراز هویت استفاده نکردم.
از سشن فقط برای ذخیره هش کپچای فرم ثبت نام استفاده کردم؛ مورد دیگه ای هم یادم نمیاد.
id رکورد اکانت کاربر و کلید لاگینش رو در یک کوکی ذخیره کردم که در هر درخواست با دیتابیس چک میشه.
کوکی ها رو اصلا نباید برای احراز هویت بکار برد. باید از همون سسشن استفاده کرد.

یه هکر می تونه کوکی های جعلی تولید کنه و برای سرور بفرسته و سیستم لاگین اجازه ورود به هکر می ده.

[eshpilen]

کوکی ها رو اصلا نباید برای احراز هویت بکار برد. باید از همون سسشن استفاده کرد.

یه هکر می تونه کوکی های جعلی تولید کنه و برای سرور بفرسته و سیستم لاگین اجازه ورود به هکر می ده.
نه دیگه اشتب نکن.
همون سشن هم داره با کوکی کار میکنه.
بستگی داره چی رو چطوری در کوکی ذخیره کنی.
مثلا سشن یک رشتهء رندوم بنام سشن آیدی رو در کوکی ذخیره میکنه.
سشن کاربر شما با همین رشته شناسایی میشه که با اسم فایل سشن باید تطابق کنه.
منم عملا همین کار رو کردم. id هم که گفتم به تنهایی کاره ای نیست و باید حتما کلید لاگین که یک رشتهء رندوم غیرقابل پیشبینی و حدس مثل سشن آیدی هست با کلید لاگین موجود در رکورد کاربری که id اش در کوکی است مطابقت کنه.
هکر عمرا نمیتونه کوکی جعلی بسازه. برای ساختن کوکی جعلی باید یک کلید لاگین معتبر رو بدونه. از کجا میاره؟ مگر اینکه در سایت ثبت نام کنه و کلید لاگین خودش رو استفاده کنه که اونم میشه هک کردن خودش!! به هیچ چیز بیشتری نمیرسه از این بابت.

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

[idocsidocs]

همون سشن هم داره با کوکی کار میکنه.
سسشن این کارو می کنه چون مجبوره یه راه برای شناسایی ارتباط بین کلاینت و سرور داشته باشه. ولی ما که مجبور نیستیم این کارو انجام بدیم. بجای این کار یه رشته sha1 از سسشن آی دی، آی پی و یوزر ایجنت ایجاد کنیم و توی سسشن نگه داری کنیم بهتره.


هکر عمرا نمیتونه کوکی جعلی بسازه.
می تونه بین مسیر کلاینت و سرور قرار بگیره و کوکی ها رو بدزده.

[Unique]

دوست عزیز ! شما دارین اشتباه میکنید session ها کلا بر پایه کوکی ها استوارد هستند ! کوکی اصلا چیز خطرناکی نیست اگه درست استفاده بشه ! خودم اصلا از session استفاده نمیکنم چون واقعا بهش نیازی ندارم. صحبتی که eshpilen میکنه درسته وکاملا میشه بدون session و با کوکی انجامش داد ! هیچ خطر امنیتی هم سایت را تهدید نمیکنه.


می تونه بین مسیر کلاینت و سرور قرار بگیره و کوکی ها رو بدزده.
همین کار را با session میتونه انجام بده ! کافیه cookie مروبط به session id شما را گیر بیاره و تموم ! اما این کار به این سادگی ها نیست از طریق شبک مگه اینکه سایت شما open xss باشه و اگه خیلی بابت مشکل شبکه و port sniff نگران هستید از SSL استفاده کنید.

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

[idocsidocs]

صحبتی که eshpilen میکنه درسته وکاملا میشه بدون session و با کوکی انجامش داد ! هیچ خطر امنیتی هم سایت را تهدید نمیکنه.
از نظر من کار درستی نیست

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

البته اگه کاربر توی فرم لاگین، تیک یادآوری رو زد باید از کوکی استفاده کرد.

من موقع لاگین فقط از این دو مورد استفاده می کنم.

[eshpilen]

بجای این کار یه رشته sha1 از سسشن آی دی، آی پی و یوزر ایجنت ایجاد کنیم و توی سسشن نگه داری کنیم بهتره.
این رو میشه براحتی در همون رکورد اکانت کاربر در دیتابیس هم ذخیره کرد.
نیازی نیست سشن باشه تا بتونیم از این کارها بکنیم.


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

البته اگه کاربر توی فرم لاگین، تیک یادآوری رو زد باید از کوکی استفاده کرد.

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

[mtchabok]

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

در ضمن چرا فکر میکنیم که اطلاعات سشن فقط میتونه در فایل ذخیره بشه ، اصلا اینطوری نیست . شما میتونید با قابلیت به نام هندلر در php محل ذخیره سازی اطلاعات سشن رو تغییر بدید و همینطور عملکردش رو عوض کنید و اصلا محدودیتی در این ضمینه وجود نداره ، در ضمن اصلا می تونید تنظیمات پیش فرض سشن رو هم بیخیال بشید و هرچی تنظیمی که دوس دارید در هندلر ایجاد و استفاده کنید .
http://php.net/manual/en/class.sessionhandler.php

[eshpilen]

در ضمن چرا فکر میکنیم که اطلاعات سشن فقط میتونه در فایل ذخیره بشه ، اصلا اینطوری نیست . شما میتونید با قابلیت به نام هندلر در php محل ذخیره سازی اطلاعات سشن رو تغییر بدید و همینطور عملکردش رو عوض کنید و اصلا محدودیتی در این ضمینه وجود نداره ، در ضمن اصلا می تونید تنظیمات پیش فرض سشن رو هم بیخیال بشید و هرچی تنظیمی که دوس دارید در هندلر ایجاد و استفاده کنید .
http://php.net/manual/en/class.sessionhandler.php
آره اینا رو میدونیم.
ولی بدون استفاده از سشن هم میشه و بنظر من کار برنامه نویسیش ساده تر و سریعتر هم میشه (البته با اون سیستم حرفه ای و تشکیلات امنیتی کاملی که مد نظر بنده بوده).
لزومی نداره خودمون رو با جوانب مختلف سشن درگیر کنیم وقتی بهرحال حداقل یک رکورد در دیتابیس به ازای کاربر داریم و در هر درخواست ارتباط با دیتابیس ضرورت داره. میتونم سشن رو به کلی حذف کنیم.
البته سشن رو برای احراز هویت و اینها حذف میکنیم. برای مواردی که نیاز به ذخیره سازی موقت اطلاعات دارن میشه از سشن هم استفاده کرد.

[idocsidocs]

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

[eshpilen]

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

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

[idocsidocs]

خودت می پرونی حواست نیست!

سسشن توی سرور هست ولی کوکی روی کلاینت!

[eshpilen]

خودت می پرونی حواست نیست!

سسشن توی سرور هست ولی کوکی روی کلاینت!
سشن هم یه کوکی داره که سشن آیدی توش ذخیره میشه.
بقیهء دیتاها بله روی سرور در فایل ذخیره میشن.

سیستم منم یه کوکی داره که کلید لاگین (معادل سشن آیدی شما) درش ذخیره میشه.
بقیهء دیتاهاش هم روی سرور در دیتابیس ذخیره میشن.

خب؟ ایرادی، نظری، انتقادی، پیشنهادی :متفکر:

[idocsidocs]

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

سفارشی که گرفتم داره عقب میافته!!!!!!!!!!

[tehro0n]

من که میگم به جای این بحث ها بیان طرز کوئری گرفتن صحیح رو در http://barnamenevis.org/showthread.php?379292-%D9%86%D9%85%D8%A7%DB%8C%D8%B4-%D8%AA%D8%B9%D8%AF%D8%A7%D8%AF-%D8%A8%D8%A7%D8%B2%D8%AF%DB%8C%D8%AF%D9%87%D8%A7%D B%8C-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%A7%D9%86 بنویسید، اینجوری به یه نفر خیری میرسه!

[Unique]

بازم جالب بود ! البته که لازمه هر کسی اونجور که فکر میکنه درسته کد بزنه ، وگرنه فرقی بین دو تا Developer به وجود نمیومد ! (کسی به خودش نگیره ها کلی گفتم ;)) اما به دوست خوبم idocsidocs توصیه میکنم مقالات بیشتری در مورد cookie ها بخونه و چندین نوع پیاده سازی سیستم Login را ببینه ! توی سایت هایی نظیر stackoverflow زیاده ...