در بخش اول مقاله(برای مشاهده کلیک کنید.)، به بررسی و معرفی مفاهیم دخیل در بروز مغایرت و سناریوهای مختلف پرداختیم. در این مقاله تجربیات و الزاماتی را در راستای کاهش و مدیریت بهتر خطاها و جلوگیری حداکثری از بروز مغایرت مطرح میکنیم.
زمانی که کاربر پس از انتخاب محصول و تکمیل اطاعات لازم، روی گزینه پرداخت کلیک کند تا وارد درگاه پرداخت شود.؛ سه مرحله زیر به ترتیب اتفاق می افتد:
1) ثبت درخواست کاربر و الگوریتم پیش از ورود به درگاه و انتقال کاربر به درگاه(Before Payment)
2) پرداخت توسط کاربر در درگاه
3) بازگشت کاربر به نرم افزار، تایید پرداخت و ارائه خدمات توسط سیستم(After Payment)
این سه مرحله متوالی، از ضریب حساسیت بسیار بالایی برخوردار هستند. بنابراین برای جلوگیری از خطاهای رایج، حتما نکات زیر را پیاده کنید.
ممکن است از زمان تصمیم گیری کاربر برای خرید تا زمانی که اطلاعات خود را تکمیل میکند و دکمه پرداخت را میزند، فعل و انفعالات از جمله تغییر قیمت محصول، ناموجود شدن محصول و موارد مشابه اتفاق بیفتد. بنابراین حتما و حتما باید تمامی موارد حساس مجددا توسط سیستم محاسبه شود و سپس در صورت عدم وجود مشکل کاربر به درگاه منتقل شود. به زبان دیگر، محاسباتی که تا زمان رسیدن کاربر به این مرحله اتفاق افتاده، به هیچ وجه قابل اعتماد نیست و همگی باید مجددا توسط سیستم بررسی شود.
1) قیمت ها بررسی شود.
2) موجود بودن کالا بررسی شود.
3) مجاز بودن کاربر برای خرید بررسی شود.
4) در صورت ورود کد تخفیف توسط کاربر، اعتبار کد تخفیف مجددا بررسی شود.
5) سایر ملاحظات حساس که در کسب و کار وجود دارد.
سناریوی غلط پنهان در پرداخت را نادیده نگیرید!!!
زمانی که شما به عنوان توسعه دهنده در حال تست سیستم هستید، ممکن است متوجه مشکلاتی که ممکن است در همزمانی رخ دهد نباشید. در صورتی که تجربه کافی نداشته باشید، ممکن است سناریوی غلط زیر را نادیده بگیرید.
زمانی که چند متقاضی برای خرید یک کالا وجود دارد و این کالا یکتاست و یا فقط به تعداد کمی از محصول در انبار وجود دارد، آنگاه اگر محصول را با ورود یک کاربر به درگاه رزرو نکنید، مشکل زیر به وقوع خواهد پیوست.
اگر رزرو کردن موقت محصول را فراموش کنید، همانطور که در تصویر فوق میبینید، از نظر سیستم هنوز کالا برای هر دو متقاضی موجود است، چرا که هنوز هیچ یک به مرحله ارائه محصول نرسیده اند، بنابراین هر دو اشتباها وارد درگاه میشوند و کاربری که دیرتر از درگاه خارج میشود دچار مشکل خواهد شد. اما سناریوی درست به صورت زیر است.
طول زمان رزرو موقت را بیشتر از مدت مجاز برای پرداخت در درگاه بگذارید.
پس از تکمیل بازگشت کاربر از درگاه پرداخت، قبل از ارائه خدمات مجددا تمام موارد حساس را بازبینی کنید و اگر مشکلی وجود نداشت خدمات را ارائه کنید.
گاهی حفره های امنیتی زمانی ایجاد میشوند که داده های حساس سیستم را از کلاینت دریافت کنید. مثلا در یکی از مراحل سفارش گیری، قیمت را پس از محاسبه به کاربر اعلام میکنید و سپس به دلایل مختلف(مثلا عدم محاسبه مجدد قیمت به دلیل پیچیدگی) همان قیمت را از کاربر دریافت میکنید و او را با همان مبلغ به درگاه میفرستید. قاعدتا اگر شخص هکری از این موضوع اگاه شود، به سادگی با تغییر در قیمت، با مبلغ بسیار پایین خدمات را دریافت خواهد کرد.
البته شاید سناریوی مطرح شده بدیهی به نظر برسد، اما موارد متعددی وجود دارد که به دلیل پیچیدگی سیستم و کم تجربگی، از دید توسعه دهنده دور میماند. بنابراین همیشه داده های حساس قابل محاسبه توسط سیستم را در تمامی مراحل حساس مثل پرداخت، مجددا محاسبه کنید و از Client داده حساسی را دریافت نکنید.(در سناریوی فوق در Before مجددا قیمت را محاسبه کنید و از کاربر فیلد قیمت نگیرید.)
زمانی که کاربر در درگاه پرداخت اطلاعات کارت را وارد نموده و روی دکمه تکمیل پرداخت کلیک میکند، توسط سرویس بانک به یک ادرس اینترنتی از نرم افزار ما منتقل میشود.(ادرس After Payment) ممکن است کاربر بارها و بارها این صفحه از نرم افزار را رفرش کند. در این زمان چه اتفاقی خواهد افتاد؟ اگر الگوریتم شما به دلیل عدم شناخت صحیح سرویس بانک و یا کم دقتی به گونه ای نوشته شده باشد که با هر بار رفرش و دریافت پیام موفق، خدمات را مجددا ارائه کنید، آنگاه به ازای یک پرداخت چندین بار خدمات داده اید. بنابراین حتما موضوع Double Spanding را تست نموده و از صحت عملکرد سیستم در چنین مواردی اطمینان حاصل کنید.
ترجیحا ساز و کاری ایجاد کنید که در صورت رفرش صفحه پرداخت توسط یک کاربر در یک بازه زمانی مشخص(مثلا 1 دقیقه) خود به خود با نمایش پیام مناسب از انجام الگوریتم AfterPayment جلوگیری شود.(به زبان عامیانه اگر کاربر تا یک دقیقه، ادرس After رو رفرش کرد، بفرستیدش به فلوی عملیات مشکوک و اجازه اجرای الگوریتم اصلی پرداخت رو ندید.)
اگر از پایگاه داده RDBMS استفاده میکنید، در هیچ یک از بازبینی های فوق از ORM به هیچ وجه استفاده نکنید. ORM به دلیل کندی که به صورت ذاتی ایجاد میکند، امکان محاسبات لحظه ای و دقیق را از بین میبرد و قطعا با مشکل مواجه خواهید شد.
در مراحل پرداخت به هیچ وجه Exception مدیریت نشده‌ای باقی نگذارید. در تمامی بلاک های خاص و حساس بر حسب الگوریتم پرداخت، Exception ها را مدیریت کنید و در صورت بروز آنها عملیات صحیحی را انجام دهید. به طور مثال گاهی ممکن است مدیریت یک Exception مشخص کننده ناموفق بودن عملیات باشد و پول کاربر را بازگردانید و در یک قطعه کد دیگر ممکن است Exception به معنی نامشخص بودن نتیجه عملیات باشد و به کاربر پیام خطای مناسب نمایش داده و مبلغ را تا زمان مشخص شدن علت مشکل نزد خود نگه دارید.
در تمامی قسمت های حساس و مهم که ممکن است خطایی رخ بدهد لاگ ثبت کنید. لاگ ها، نیروهای ویژه و قدرتمندی برای تشخیص و رفع مغایرت هستند.
تمامی کدهایی که توسعه داده اید را تست کنید و هیچ یک را به صورت پیشفرض صحیح و بدیهی تصور نکنید.
اگر این مقاله برای شما مفید بود لطفا با سایر دوستان به اشتراک بگذارید.
مقاله مرتبط قبلی (بخش اول مقاله)
شما میتوانید این مقاله را در وبسایت آموزشی من به آدرس زیر مشاهده نمایید.
برای پیگیری آموزش ها و مقالات بیشتر، به صفحه لینکدین و وبسایت من سر بزنید.
