بررسی یک مورد مهم در لاراول 7 - same site و حذف شدن سشن auth

@m.mahdavi97
ممنون برای توجه دوباره به این موضوع، برای من هم خیلی جالبه که این موضوع رو اساتید بزرگوار خیلی اهمیتی بهش ندادن با اینکه تا بحال خیلی مورد سوال بچه ها بوده ،خیلی از درگاه ها با متد get کال بک میکنن و مشکلی هم پیش نمیاد مثل زرین پال ولی بانک ملت post هست و سایر ماجرا ... تست کردنش با یه فرم که متد پست داره روی یک دامین مجزا کاملا امکان پذیره و خواهید دید که روی لاراول 7 واقعا کاربر لاگ اوت میشه
بنده هم مشکلم رو با همون روشی که آقا بهزاد گفتن حل کرده بودم و البته من توی env چیزی اضافه نکردم و مشکلی هم ندارم و درست کار میکنه فقط مشکلی که میمونه مقدار none برای مرورگرهای قدیمی تر ساپورت نمیشه
در کل اگه این مساله same_site بصورت تخصصی بهش پرداخته بشه بخصوص در مورد لاراول و بصورت یک مقاله در سایت راکت ارائه بشه بنظر بنده محتوای بسیار خوب و مفیدی خواهد بود
@hesammousavi

@behvandi11
@m.mahdavi97

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

شما این مشکل رو به چه روشی حل کردین؟

@behzadd
سلام ، ببخشید دیر جواب میدم
مشکل ساپورت مرورگر رو من راستش فرصت نکردم جستجو و بررسی بیشتری بکنم
بنظرم میشه با تشخیص مرورگر کاربر برای مرورگرهای قدیمی تر sameSite رو تغییر داد ولی با تغییرش هم باز اون مشکل لاگ اوگ پیش میاد قریب به یقیین 🤦‍♂️
شاید توی لاراول 8 این مشکل برطرف شده باشه

@behvandi11
مرسی . ظاهرا با مجموعه ای از شاید ها طرفیم!

@m.mahdavi97
@wozniak
دوستان مقدار same_site رو به null تغییر بدید بدون سینگل یا دبل کوتیشن
مشکل باید حل بشه من تست گرفتم توی مرورگرهای قدیمی که با مقدار none مشکل داشت با null کار میکنه توی مرورگرهای جدید هم اوکیه
لطفا شما هم تست بگیرید و نتیجه رو اعلام کنید که اگه اوکیه بقیه دوستان هم استفاده کنن

@behvandi11
برای لاراول چند تست کردید؟

@wozniak
لاراول 7.3.0

@behvandi11
لطفا در صورتی که تستون به مشکل خورد اینجا به ما اطلاع بدید

@m.mahdavi97
@behvandi11
سلام دوست عزیز
لطفا ضمن اینکه نتیجه تست خود برای قرار دادن مقدار same-site رو به null به ما بگید،
یه پکیجی هست که یه middleware ساخته که مشکل samesite رو حل میکنه ظاهرا . من امتحان نکردم گفتم اول share کنم ببینم دوستان چه میگن
https://github.com/kevinsmith/laravel-samesite-none-compat

یه مطلب دیگر هم هست. same-site با یه ورژن هایی از تقریبا تمام مرورگر ها به غیر از فایرفاکس مشکل داره. مقاله زیر این ورژن ها رو شناسایی کرده
https://www.chromium.org/updates/same-site/incompatible-clients
کافیه یه middleware بنویسیم که ورژن ها رو detect کنه و موقعی که یوزر با اون ورژن میاد same-site رو به مقدار none ست نکنیم بلکه مقدار default خودش باشه.
نظر شما چیه ؟؟ مرسییی

@behvandi11
@m.mahdavi97
متاسفانه مقدر null واسه ورژن 5.7 به مشکل خورد!

@m.mahdavi97
@behvandi11
عرض ادب خدمت دوستان
( به دلیل اینکه ست کردن samesite به مقدار none دارای uncampatibility هست با یه سری از مرورگرها و ورژن های خاص این مطلب رو دوباره باز میکنم)
ما با مشاوره یک سری موارد با پشتیبان های درگاه پرداخت به این نتیجه رسیدیم که samesite رو از سیکل verify پرداخت ( قسمت callback ) حذف کنیم. در واقع این پیشنهاد رو اون دوستان مطرح کردند و فرمودن صاحبان تراکنش زیاد هم این کارو کرده اند.
و اون کار اینه که به وسیله ی saleOrder , refId که در درگاه ملت مثلا تو کال بک فرستاده میشه به ما ، و دیتایی که قبل از درخواست برای پرداخت ذخیره می کنیم ( و به نحوی به این دیتاها bind شده ) بفهیم این پرداخت مال کدوم یوزر و کدوم سفارش بوده و کل این کارها رو مستقل از سشن و کوکی و auth و ... انجام بدیم.
ما اینکار رو در middleware و قبل از اجرای تمام middleware های دیگه انجام دادیم ( از لحاظ pirority ) و در مرحله تست هست.
و باید اون مقدار samesite به مقدار default خودش ست بشه ( و یا باید به مقداری ست بشه که مرورگر ها باهاش مشکل ندارند ) که مراحل سفارش به درستی اجرا بشه. ( چه مقداری هست که با هیچ کدوم از مرورگرها مشکل compatiblity نداره ؟؟)

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

البته باز هم این اتفاق افتاده ، یعنی حتی قبل از اینکه درخواست به middleware برسه ( که اولین middleware هست ) خود براوسر کوکی ها رو حذف و unvalidate میکنه ( در بعضی موارد )
حالا سوال من اینه که این کد هایی که عرض کردم که به وسیله ی اون ها سفارش رو بازیابی کنیم و وضعیت پرداختش رو بررسی کنیم ، کجا باید قرار بگیره که قبل از اینکه براوسر کوکی رو بررسی کنه ما کارمون رو بکنیم!!

@m.mahdavi97
@behvandi11

با تغییر priority برای middleware ی که کدههای وریفای رو در خودش داره تونستیم این مشکل رو حل کنیم تقریبا.
الان بدون وابستگی به سشن و کوکی ( مقدار کوکی به null ست شده بدون کوتیشن ) پرداخت کاربران validate میشه.
این روش بنظر میرسه فعلا قابل اعتماد هست تا بعد!

@wozniak
سلام ، روشی که می فرمایید در صورتی که کاربر چند دقیقه توی درگاه بانکی باشه و بعد کال بک اتفاق بیفته فکر می کنم باز هم منجر به لاگ اوت کاربر میشه ولی قبل از لاگ اوت با اون جریان priority اطلاعات تراکنش رکورد میشه ، اگر اشتباه میگم شما اصلاح بفرمایید
یه روش دیگه ای رو هم پیشنهاد میدم که احتمال زیاد کار میکنه، خودم تست نگرفتم چون تا حالا اونقدر کاربرای با مرورگر قدیمی برام بااهمیت نبوده
1)پکیج زیر رو نصب کنید:
https://github.com/jenssegers/agent
کارش تشخیص مرورگر کاربر با جزییات دقیق هست و مواردی از این دست

2)بعد میدلور زیر رو بسازید:
https://gist.github.com/jedimdan/e6c78a2665f788eda9a3e3f3b4e1f982

مجموع این دو کار باعث میشه مقدار متناسب با ورژن مرورگر برای samSite ست بشه ، این کار باید درصد قابل قبولی رو کاور کنه

@behvandi11

بله کاربر احتمال داره داخل مرورگر گوگل کروم logout بشه. و تو تست های ما هم بوده که این اتفاق افتاده اما مشکلی در وریفای تراکنش به وجود نمیاد

سلام دوستان
پیشنهاد بنده تغییر مقدار path در فایل session config هست.

'path' => '/;SameSite=None; secure'

روش دوم
تغییر فایل htaccess

<ifmodule mod_headers.c>
Header append Set-Cookie ;SameSite=None;Secure
</ifmodule>

سلام .

این اتفاق در verify یا همون برگشت از پرداخت میوفته و معمولا ارورش هم اینه که :
سفارش شما از قبل تایید شده است و ی کدی رو برمیگردونه مثلا 1543 و این به این معنی هستش که پرداخت انجام شده اما تو برگشت از بانک به مشکل samsite خورده . شما میتونید همونجا کدی که به عنوان خروجی برمیگردونه رو بگیرید مثلا همین 1543 و payment رو برابر 1 یعنی پرداخت شده و تایید شده قرار بدید و ریدایرکت کنید به سایت خودتون و همچی به خوبی خوشی تموم بشه تا اینکه اینجا کلی تست و راه حل امتحان کنید تهشم به نتیجه ای نرسه !

این کاری بود که خودم کردم و الان همه چی اوکیه .
موفق باشید