سیستمعامل فروشگاه، بخش ۲: ورود با کد پیامکی برای بازار ایران
چرا تیتان پرداخت و ورود را یک عمل واحد میداند، محدودیتهای نرخ کد یکبارمصرف چطور طراحی شده، و جزئیات کاوهنگاری که کد را حتی ساعت ۱۱ شب هم میرساند — سشن ۴ از ساخت فروشگاه خودمان.
تصمیمی که همهچیز بعدی را شکل داد
سشن ۴ از ساخت تیتان — فروشگاه چاپ سهبعدی خودِ ما، نه یک همکاری با مشتری — یک تصمیم گرفت که هر چیز بعدی به آن وابسته است: تأیید شماره تلفن در لحظه پرداخت، همان عمل ورود به حساب است. فرم ثبتنام جداگانهای وجود ندارد. مهمانی که شمارهاش را برای ثبت سفارش تأیید میکند، همزمان حسابش هم ساخته میشود. بیشتر خریداران ایرانی دقیقاً یک بار تأیید شماره را تحمل میکنند، و باید همان باری باشد که سفارششان را هم میگیرند — نه یک مرحله دوم و اختیاری که هیچکس کامل نمیکند.
سه محدودیت نرخ، از ارزانترین شروع
درخواستهای کد یکبارمصرف از سه محدودیت نرخ مستقل در KV عبور میکنند، عمداً به ترتیب
ارزانترین بررسی اول: یک سقف ساعتی بر اساس IP، سپس یک سقف روزانه بر اساس شماره، سپس یک
بازه ۱۰ دقیقهای تنگ بر اساس شماره. یک هجوم سوءاستفادهآمیز پیش از آنکه سیستم هزینه
بررسیهای گرانتر را بپردازد، توسط اولین و ارزانترین بررسی رد میشود. این را زنده تست
کردیم، نه فقط با خواندن کد: چهار درخواست سریع کد برای یک شماره، سه بار 200 و بار چهارم
429 برگرداند — دقیقاً همانطور که طراحی شده بود.
باگی که پیش از رخ دادن، دورش طراحی کردیم
کد ۵ رقمی با یک زمان انقضای مطلق ذخیره میشود که عمداً از TTL خودِ لایه ذخیرهسازی جدا نگه داشته شده. دلیلش: هر حدس اشتباه یک شمارنده تلاش را افزایش میدهد که دوباره در KV ذخیره میشود — و یک TTL نسبی سادهلوح با هر بار ذخیره، بیصدا جلو میرفت و عمر کد را با هر حدس اشتباه طولانیتر میکرد. جدا کردن «این کد کِی منقضی میشود» از «ورودی ذخیرهسازی کِی منقضی میشود»، این حفره را از پایه میبندد، نه با امید به اینکه کسی متوجه نشود.
قفل شدن سخت است: پنج حدس اشتباه و شماره قفل میشود، حتی اگر حدس ششم دقیقاً همان کد درست
باشد. این را هم زنده تأیید کردیم: پنج حدس اشتباه همگی invalid_code برگرداندند، و
تلاش ششم با کد واقعاً درست هم همچنان too_many_attempts برگرداند.
چرا دقیقاً ارسال الگو-محور کاوهنگار
ارسال پیامک از طریق سرویس VerifyLookup کاوهنگار انجام میشود — یک API الگو-محور تراکنشی، متمایز از endpoint متنآزاد که بعداً برای کمپینهای تبلیغاتی در ساخت استفاده شد. این تمایز اهمیت دارد چون ایران یک بلکاوت شبانه روی پیامکهای تبلیغاتی اعمال میکند؛ ارسالهای الگو-محور تراکنشی از آن معافاند. مشتریای که ساعت ۱۱ شب پرداخت میکند نباید تا صبح منتظر کد ورودش بماند، و ساخت مسیر احراز هویت روی endpoint اشتباه پیامک، این را بهطور تصادفی واقعی میکرد.
چه چیزی بعد میآید
بخش اول این مجموعه هسته تجاری و موتور دهعاملی کرون را پوشش میدهد که این سیستم احراز هویت به آن تغذیه میکند — سیستمعامل فروشگاه، بخش ۱ را ببینید. داستان کامل ساخت در /fa/work/titan است. اگر محصولتان به احراز هویتی نیاز دارد که واقعاً با شکل تأیید هویت در بازار شما همخوانی داشته باشد — نه یک فرم عمومی ایمیل/رمز عبور — درباره ساخت فروشگاه آنلاین با ما بخوانید.
چکلیستی برای پروژه خودتان میخواهید؟
بگویید روی چه چیزی کار میکنید — ظرف ۴۸ ساعت با یک طرح اولیه معماری پاسخ میدهیم.
پست بعدی: سیستمعامل فروشگاه، بخش ۱: عاملهای تجاری روی Workers و D1