# زبان های اسکریپتی > PHP > Laravel Framework >  تغییر مراحل ثبت نام user

## pary_daryayi

سلام دوستان.من تو پروژه ام میخوام قسمت auth و ثبت نام رو تغییر بدم .بعنوان مثال فیلدهایی به جدول user اضافه کردم : phone , address,city,postCode .در مرحله ی اول میخوام کاربر اینها رو فقط پر کنه : name , emaile ,password,phone و بعد از اینکه کدی به موبایلش ارسال شد و کاربر درست وارد کرد بعد از اون ثبت ، لاگین و ریدایرکت اتفاق بیفته . و در مراحل بعد مابقی اطلاعات مثل ادرس و ... رو پر کنه
یه مقدار با تحلیل مراحل کار مشکل دارم :
یک  : ایا منطق کار اینه که اول کد فعال سازی ارسال بشه و اگر درست بود اطلاعات نام ، ایمیل و ... در پایگاه ثبت بشه ؟
 دو : آیا برای ارسال کد قبل از رجیستر ، میبایست یک middleware نوشت ؟ یا  روندش شبیه فعال سازی ایمیل هست ؟

ممنون میشم کلیت کار و مراحل و منطق رو توضیح بدید .

----------


## plague

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

من معمولا یه میدلور کلی دارم برای همه لینک های سمت کاربری 
تو میدلور میگم که اگه کاربر لاگین شده بود چک کن اکانتش رو تایید کرده یا نه اگه تایید نکرده بود بفرستش تو صفحه تایید sms
اگر تایید کرده بود چک میکنم اطلاعات پروفایلش رو تکمیل کرده یا نه اگه نکرده بود میفرستمش تو صفحه تکمیل اطلاعات 
اگر این رو هم تکمیل کرده بود که دیگه ولش میکنم آدرسی که زده براش لود بشه

----------


## pary_daryayi

ممنونم از شما . تمام سوالات منو  تو همه انجمن ها تنها شما دارید جواب میدید ... 

راستی نیاز نیست که کد تایید در پایگاه ذخیره بشه درسته ؟ من در سشن قرار میدم . 
ایا شما هم زمانی مثلا 60 ثانیه برای تایید کد قرار میدید ؟ 
مثلا من یک چنین middlewar ای نوشتم که هروقت کاربر وارد صفحه ی تایید sms شد و بیش از شصت ثانیه زمان برد ریدایرکت بشه . ولی مثل اینکه منطق و نحوه ی کدم اشتباهه که کار نمیکنه .



public function handle($request, Closure $next)
{
    if (auth()->check()) {

        $expire_verify =date('H:i:s', strtotime('+60 second'));
        if(date('H:i:s')>$expire_verify){
            $msg ='your error message';
            return redirect()->back()->with('invalid', $msg);
        }
    }
    return $next($request);
}

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

----------


## pary_daryayi

و اینکه دیدم یک پکیجی به نام nexmo برای ارسال sms نصب میشه. شما هم از این استفاده میکنید ؟

----------


## plague

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

کد باید بره تو دیتبایس از سشن استفاده نکن 
محدودیت زمانی برای تایید sms استفاده میشه معمولا برای اینکه ینفر از کد های قدیمی استفاده نکنه

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

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

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

این که شما میگی میدلور نوشتی برای ریدایرکت کردن کاربر بعد از 60 ثانیه مشخصه که هنوز متوجه نشدی که وب چجوری کار میکنه 
اجرای یک صفحه وب 2 بخش داره یکی سمت سرور و یکی سمت کلاینت 
وقتی شما یک آدرس رو میزنی کد های php (میدلور و کنترلر ) توی سرور اجرا میشن بعد نتیجه اجراشون به همراه کد های ویو به مرورگر کاربر ارسال میشه و مرورگر کاربر کد های کلاینت (html/css/js ) رو اجرا میکنه و نتیجه رو به کاربر نشون میده 
همه کد های php قبل از ارسال به مرورگر کاربر اجرا و تمام میشن ... به عبارت دیگه وقتی صفحه لود شد برای کاربر کد های php هیچ اثری ندارن و هیچ کاری نمیتونن بکنن و اجرا نمیشن .. چون الان تویمرورگر کاربر هستی و فقط کد هایی که سمنت کاربری هست (javascript ) میتونن اجرا بشن 

پس شما نمیتونی با php  مرورگر کاربر رو کنترل کنی که بعد از 60 ثانیه ریدایرکت شو ! 



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

توی این میلدور چک میکنی اگه کاربر لاگین بود و تایید نکرده بود اکانتش رو بفرستش به راوت تایید اکانت 
اینجوری بعد از ثبت نام و لاگین اصلا نیاز نیست کاربر رو بفرستی به راوت تاییدد اکانت یا چک کنی که تایید کرده یا نه اکانتش رو میدلور خودش اینکارارو انجام میده
برای تایمر هم باید با js بنویسی هرکاری که میخای انجام بشه پس از پایان 60 ثانیه 

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

----------


## pary_daryayi

ممنونم از شما . خیلی خوب توضیح دادید.

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

من میدل ور رو فعلا به این شکل نوشتم :

public function handle($request, Closure $next)
{
    if(!Auth::check()){
        return redirect('/');
    }
    if(auth()->user()->status == 1){
        return $next($request);
    }
    if( auth()->user()->status == 0){
        return redirect('check-code');
    }

}

status برای حالتی هست که کد تایید رو وارد کرده یا نه .

----------


## plague

1 - من پاک نمیکنم ولی مشکلی هم نداری پاک خاستی بکنی 
2 - بله  , اگر کاربر لاگین شده تایید نکرده بود باید به صفحه تایید ریدایرکت بشه پس از لاگین 
نمیدونم چرا تو خط اول میدلورت نوشتی که اگه لاگین نبود ریدایرکت بشه به صفحه اول معنی نمیده اگه میخای این میدلور رو روی همه رات ها بندازی 
اینجوری کاربری که لاگین نیست فقط میتونه صفحه اول سایت رو ببینه 


public function handle($request, Closure $next)
{
    if( Auth::user() && Auth::user()->status  != 1  &&  !in_array( $request->route()->getName() , ['check-code'] ) ){
        return redirect('check-code');
    }
   
    return $next($request);
}



میگیم اگه یوزر لاگین بود و استاتوسش 1 نبود ریدایرکتش کن به صفحه تایید کد وگرنه اگه لاگین نبود یا لاگین بود و تایید کرده بود بزار به کارش ادامه بده 
شرط سوم یعنی

in_array( $request->route()->getName() , ['check-code'] ) 


برای اینه که ما نمیخایم این تیکه کد توی خود صفحه تایید اجرا بشه دیگه
از اونجایی که کد توی میدلور قبل از کد های کنترلر و ویو اجرا میشه , شما میخای بری تایید کنی اکانتت رو ولی قبل از اینکه فرصت تایید رو داشته باشی این کد دوباره ریدایرکتت میکنه به همون صفحه تایید و  کاربر رو  توی یک حلقه بدون انتهای ریدایرکت میفته
باید کاری کنی که این شرط روی هیچکدوم از راوت های تایید کد اجرا نشه

----------


## pary_daryayi

> 1 - 
> نمیدونم چرا تو خط اول میدلورت نوشتی که اگه لاگین نبود ریدایرکت بشه به صفحه اول معنی نمیده اگه میخای این میدلور رو روی همه رات ها بندازی 
> اینجوری کاربری که لاگین نیست فقط میتونه صفحه اول سایت رو ببینه


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


public function handle($request, Closure $next)
{

    if(!Auth::check()){
        return redirect('/login');
    }
    if( Auth::user() && Auth::user()->status  != 1  &&  !in_array( $request->route()->getName() , ['check.code','change.mobile'] ) ){
        return redirect('check-code');
    }

    if( Auth::user() && Auth::user()->status  == 1  &&  !in_array( $request->route()->getName() , ['user.profile'] ) ){
        return redirect('user-profile');
    }
    return $next($request);

}

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

و البته ا redirect از login رو دستکاری کردم . یعنی کاربری که لاگین شده و تایید کد انجام نداده بلافاصله ریدایرکت بشه به تایید کد . ایا منطقی و درسته که در این مرحله انجام بشه ؟ 



protected function redirectTo()
{
    if( auth()->user()->status == 0){
        $verify = rand(1000,1999);
        $data =[ 'user-id'=>  auth()->user()->id,'verify'=>$verify,'user-phone'=> auth()->user()->phone ];
        session()->put('phone_verify',  $data);

        $dataUser = [

            'verify'   => $verify
        ];
        auth()->user()->where('id', auth()->user()->id)->update($dataUser);
        return '/check-code';

    }
    return '/home';
}

و ببخشید سوالاتم زیاد شد.
بررسی شصت ثانیه بعد از ارسال کد باید توسط update_at از کاربر و زمان فعلی صورت بگیره درسته ؟
نمیدونم باید کجا بنویسم و به چه شکل ... فقط ممنون میشم روال کار رو بگید.
من فکر میکنم باید اگر از مثلا شصت ثانیه گذشت کد قبلی expire بشه و در صورتی که کاربر روی ارسال مجدد کد زد ،کد جدید ارسال بشه.
و ایا اینها باید در صفحه ی check-code انجام بشه ؟

----------


## plague

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




> و البته ا redirect از login رو دستکاری کردم . یعنی کاربری که لاگین شده و  تایید کد انجام نداده بلافاصله ریدایرکت بشه به تایید کد . ایا منطقی و  درسته که در این مرحله انجام بشه ؟


نه نمیدونم چرا اینکارو میکنی و این redirectTo رو چجوری استفاده میکنی ... آیا بعد از لاگین این رو فراخوانی میکنی ؟ 




> و فقط  چرا میفرمایید نباید  کد تایید رو در سشن ریخت ؟ بخاطر امنیت ؟


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






> بررسی شصت ثانیه بعد از ارسال کد باید توسط update_at از کاربر و زمان فعلی صورت بگیره درسته ؟
> نمیدونم باید کجا بنویسم و به چه شکل ... فقط ممنون میشم روال کار رو بگید.
> من فکر میکنم باید اگر از مثلا شصت ثانیه گذشت کد قبلی expire بشه و در صورتی که کاربر روی ارسال مجدد کد زد ،کد جدید ارسال بشه.
> و ایا اینها باید در صفحه ی check-code انجام بشه ؟



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

این نمونه کد تایمر و ارسال دوباره کد 


https://jsfiddle.net/Lj3z9ne6/1/

----------


## behzadamin12

تو *دوره لاراول* به این مطالب کامل اشاره کردم
https://jobteam.ir/Course/178-Larave...g-online-store

----------


## pary_daryayi

> ن
> 
> کد قبلی رو نیاز نیست اکسپایر کنی ... تاریخ ثبتش هست تو دیتابیس اگه کاربر یک کد رو زد و خواست وریفای کنه اکانتش از دیتابیس میخونی کد رو چک میکنی تاریخ ثبتش رو اگه خیلی قدیمی نبود وریفای میکنی وگرنه اررور میدی
> /


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

----------


## plague

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





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


متوجه نمیشم تاریخ ورود کاربر چه ربطی به کد داره

----------


## pary_daryayi

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

ولی فکر میکنم باید برای verify هم جدا created_at قرار بدم . کد جدید هم که ایجاد شد زمانش رو تو همین اپدیت کنم و این زمانو با زمان فعلی مقایسه کنم و براش یک تایمی در نظر بگیرم که مثلا اگر از اون تایم بیشتر شد کد قبلی رو قبول نکنه .

----------


## plague

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

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

----------


## pary_daryayi

خیییلیی ممنونم از توضیحاتون .

این created_at که میگید زمان رجیستر کاربر هست ؟ چون من یک فیلد verify_created_at هم ساختم که هربار مقدار کد تغییر کرد این زمان هم اپدیت بشه . و با همین مقایسه رو انجام میدم .


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

----------


## plague

همه تیبل های که با میگریشن لاراول ساخته میشن یه فیلد created_at  دارن که شمان ثبت داده توی دیتبایس رو نشون میده 
مثلا اگه تیبلی داشته باشی که کد های رهگیری ارسالی برای کاربر ها رو توش ذخیره کنی فیلد created_at  هر سطر زمان ثبت شدن اکد تو دیتبایس و به عبارت دیگر زمان ارسال کد برای کاربر رو نشون میده (چون شما ثبت میکنی تو دیتبایس و بالافاصله ارسال میکنی برای کاربر ) 


24 ساعت منطقیه

----------


## pary_daryayi

> همه تیبل های که با میگریشن لاراول ساخته میشن یه فیلد created_at  دارن که شمان ثبت داده توی دیتبایس رو نشون میده 
> مثلا اگه تیبلی داشته باشی که کد های رهگیری ارسالی برای کاربر ها رو توش ذخیره کنی فیلد created_at  هر سطر زمان ثبت شدن اکد تو دیتبایس و به عبارت دیگر زمان ارسال کد برای کاربر رو نشون میده (چون شما ثبت میکنی تو دیتبایس و بالافاصله ارسال میکنی برای کاربر ) 
> 
> 
> 24 ساعت منطقیه


ممنونم ازتون . الان متوجه شدم . شما میگید جدول جدا برای کدها درنظر بگیرم در صورتی که من تو همون جدول user یک فیلد code_verify و code_created_at گراشتم و هر وقت لازم باشه اونو اپدیت میکنم.

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

----------


## plague

> ممنونم ازتون . الان متوجه شدم . شما میگید جدول جدا برای کدها درنظر بگیرم  در صورتی که من تو همون جدول user یک فیلد code_verify و code_created_at  گراشتم و هر وقت لازم باشه اونو اپدیت میکنم.


بله باید جدول جدا باشه 





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


خود سشن یا مقادیر درونش ؟ 

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

به این دلایل وقتی کاربر داره خرید میکنه توی سشن میریزی وقتی میخاست بره بانک پرداخت کنه قبل از ارسالش به بانک میریزی تو دیتبایس و سشن رو پاک میکنی که سبد خریدش خالی بشه (بعد از برگشت از بانک هم میتونی سشن رو خالی کنی شاید پرداختش ناموفق باشه و بخای سبد حفظ بشه ) 


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

----------


## pary_daryayi

بسییییار ممنونم . خیلی خوب و جامع توضیح  میدید .  :لبخند:

----------

