كيف نبني قوائم انتظار آمنة للإصدارات التجريبية على Cloudflare
لا تكون قائمة انتظار الإصدار التجريبي أصلاً تجارياً إلا إذا كانت عناوين البريد الإلكتروني حقيقية.
تبدأ معظم الفرق بحقل بريد إلكتروني واحد وزر إرسال. وهذا مناسب لتجربة صفحة هبوط. لكنه لا يكفي عندما تبدأ القائمة بتوجيه خطط الإطلاق، أو موجات الدعوات، أو تحديثات المستثمرين، أو قرارات المنتج. فإذا كان بإمكان أي شخص إرسال عنوان شخص آخر، أو كان بإمكان روبوت ملء قاعدة البيانات خلال ليلة واحدة، فستحصل الفرق على طلب مزعج بدلاً من إشارة يمكن استخدامها.
هذه هي الطريقة التي أستخدمها لبناء قائمة انتظار لإصدار تجريبي جاهزة للإنتاج على Cloudflare: اشتراك مزدوج، وفحوصات للروبوتات من جهة الخادم، وروابط تحقق قصيرة العمر، ورموز مُجزأة، وتسليم SMTP عبر استضافة البريد الحالية، وإعدادات افتراضية للمسؤول تفصل بين الصفوف التي تم التحقق منها والصفوف القديمة، وبوابة إصدار لا تتظاهر بأن البنية التحتية المُهيأة أصبحت قيد التشغيل بالفعل.
أثبت تنفيذ حديث لقائمة انتظار إصدار تجريبي فعالية هذه الطريقة في عملية تسليم حقيقية من دون الحاجة إلى نظام حسابات كامل. والجزء المفيد هو شكل العمل: واجهة تسجيل صغيرة ذات حدود واضحة حول الموافقة، وإساءة الاستخدام، والتسليم، وجودة البيانات، والنشر.
المشكلة التجارية التي تحلها قائمة الانتظار الآمنة
لقائمة الانتظار مهمتان.
ينبغي أن تجمع الطلب، وأن تساعد الفريق على التصرف بناءً عليه. وهنا تحديداً تفشل النماذج الضعيفة.
إذا لم تتمكن من الوثوق بالقائمة، فستصبح كل متابعة أبطأ. وستتساءل عن عدد الصفوف التي جاءت من الروبوتات. وستتردد قبل إرسال رسائل الدعوة. وستصدّر البيانات وتنظفها يدوياً، ومع ذلك لن تعرف ما إذا كان الشخص يسيطر على العنوان. عندها تتحول القائمة إلى مقياس شكلي تقريبي بدلاً من أن تكون أداة للإصدار.
تمنحك قائمة الانتظار الآمنة للإصدار التجريبي مدخلات أنظف:
الهدف ليس جعل النموذج البسيط معقداً. الهدف هو أن يعني النموذج ما يعتقد النشاط التجاري أنه يعنيه.
بنية Cloudflare
المكدس الأساسي صغير عمداً.
يتولى Cloudflare Workers معالجة الطلب. ويتحقق Cloudflare Turnstile مما إذا كان التسجيل يبدو بشرياً. ويخزن D1 صفوف قائمة الانتظار وسجلات التحقق المعلقة. وترسل استضافة SMTP/البريد الحالية رسالة التأكيد عبر TLS. وتزيل مهمة تنظيف مجدولة في Worker السجلات المعلقة منتهية الصلاحية.
هذا المكدس كافٍ للعديد من الفرق في المراحل المبكرة. ولا تحتاج إلى إضافة نظام حسابات مستخدمين كامل لمجرد جمع قائمة إصدار تجريبي مسؤولة.
يبدو التدفق كما يلي:
وهذا يمنح فرق المنتجات فصلاً واضحاً: الاهتمام المعلق ليس هو نفسه الطلب الذي تم التحقق منه.
الاشتراك المزدوج قرار متعلق بالمنتج
غالباً ما يُنظر إلى الاشتراك المزدوج باعتباره مسألة تتعلق بنظافة البريد الإلكتروني. أما أنا فأراه مسألة تتعلق بنظافة المنتج.
إذا كانت قائمة الإصدار التجريبي ستحدد من يحصل على الوصول أولاً، فينبغي للفريق أن يعرف أن كل عنوان يعود إلى شخص أكده. وتكفي نافذة تأكيد مدتها 24 ساعة للتسجيل العادي، كما أنها قصيرة بما يكفي لمنع الصفوف المعلقة القديمة من البقاء.
ينبغي ألا يغيّر رابط التأكيد الحالة من تلقاء نفسه. فماسحات الروابط، ومعاينات البريد الإلكتروني، وطلبات GET غير المقصودة موجودة. والنمط الأكثر أماناً هو أن يعرض الرابط صفحة تأكيد، ثم يطلب من المستخدم الضغط على زر يرسل POST من نفس المصدر.
هذه النقرة الإضافية بسيطة. لكن الحد الفاصل مفيد.
كما أنها تجعل الدعم أكثر وضوحاً. فإذا قال شخص إنه لم يسجل، يمكنك الإشارة إلى تدفق تطلب الوصول إلى صندوق البريد وإجراء تأكيد صريح قبل إدخال العنوان في القائمة التي تم التحقق منها.
حماية الروبوتات من دون جعل النموذج عدائياً
ينبغي ألا تبدو قائمة الانتظار الجيدة كاختبار أمني.
يجب أن تعمل الحماية في معظمها خلف النموذج. في هذا البناء، يتحقق Worker من أداة Cloudflare Turnstile المُدارة من جهة الخادم. ويتحقق من الرمز، والإجراء المتوقع، واسم المضيف المتوقع. أما أداة المتصفح من دون تحقق من جهة الخادم فليست سوى زينة؛ إذ يجب على Worker التحقق منها.
Turnstile مجرد طبقة واحدة. يستخدم النموذج أيضاً حقلاً كمصيدة لاكتشاف الروبوتات بتكلفة منخفضة، ونص طلب محدوداً حتى لا تهدر الحمولات الكبيرة وقت Worker، وتحديداً لمعدل الطلبات باستخدام مفتاح IP، وتحديداً لمحاولات كل عنوان باستخدام مفتاح.
ويهم الحد الخاص بكل عنوان لأن التحقق من البريد الإلكتروني قد يتحول إلى وسيلة للإزعاج. فأنت لا تريد أن يكرر شخص ما تشغيل رسائل التأكيد إلى صندوق البريد نفسه.
تبقى الاستجابة العامة عامة. وينبغي ألا تكشف ما إذا كان العنوان موجوداً بالفعل، أو ينتظر التحقق، أو مكبوتاً، أو قد تجاوز حداً معيناً. فهذا يمنع تحويل نقطة التسجيل إلى أداة لتعداد عناوين البريد الإلكتروني.
تخزين الرموز: جزّئ الشيء الذي ترسله
روابط التحقق حساسة لأنها تثبت الوصول إلى صندوق البريد.
يرسل التنفيذ رمزاً عشوائياً في رابط البريد الإلكتروني، لكن D1 يخزن فقط تجزئة مُفتاحَة لهذا الرمز. وعند التأكيد، يحسب Worker تجزئة الرمز المُرسل ويقارنها بالتجزئة المخزنة. ولا يبقى الرمز الخام في قاعدة البيانات.
يحافظ هذا التصميم على بساطة النظام مع تقليل نطاق الضرر. فإذا تسرّب جدول عمليات التحقق المعلقة، فلن يحصل المهاجم على روابط تأكيد جاهزة للاستخدام.
الرمز أحادي الاستخدام. وبعد نجاح التأكيد، يزيل Worker السجل المعلق. وتُنظف الصفوف المعلقة منتهية الصلاحية بشكل انتهازي أثناء أعمال قائمة الانتظار العادية، ومن خلال Cloudflare Cron يومي مجدول.
ويحافظ مسار التنظيف هذا على صغر حجم الجدول من دون أعمال يدوية على قاعدة البيانات.
تسليم البريد الإلكتروني عبر استضافة البريد الحالية
تمتلك العديد من الفرق استضافة بريد إلكتروني بالفعل. ولا تحتاج دائماً إلى مزود جديد للبريد الإلكتروني للمعاملات من أجل قائمة انتظار إصدار تجريبي.
في التنفيذ الذي تحققت منه، أُنشئ عنوان إرسال مخصص على استضافة البريد الحالية، ويرسل Worker عبر SMTP باستخدام TLS. الرسالة بسيطة: أكد تسجيلك في الإصدار التجريبي، والرابط صالح لمدة 24 ساعة، وتجاهل الرسالة إذا لم تطلبها.
وهذا كافٍ لهذه المهمة.
لا تكمن القيمة في تصميم بريد إلكتروني فاخر. بل في مرسل معروف، وغرض محدد، ومسار تسليم يمكن اختباره بشكل أولي قبل الإطلاق. وبالنسبة إلى شركة ناشئة، غالباً ما يكون ذلك أفضل من إضافة مزود آخر قبل أن يمتلك المنتج مستخدمين أصلاً.
ينبغي لواجهات المسؤول حماية الفريق من الافتراضات الخاطئة
الأمان لا يقتصر على نقطة النهاية العامة.
يجب أن تعكس واجهة المسؤول عقد البيانات. وينبغي أن تظهر العناوين التي تم التحقق منها افتراضياً. ويمكن أن تبقى الصفوف الأقدم غير المتحقق منها أو القديمة متاحة، لكن ينبغي أن تتطلب مرشحاً صريحاً. وينبغي أن يتبع تصدير CSV القاعدة نفسها.
يمنع هذا خطأ شائعاً عند الإطلاق: تصدير كل صف تاريخي والتعامل معه كما لو كان طلباً مؤكداً.
في تنفيذ حديث، كانت قائمة الإنتاج تحتوي بالفعل على عناوين قديمة قبل نموذج التحقق الجديد. وتحافظ خطة الترحيل على هذه العناوين كإدخالات قديمة. ولا تضع علامة التحقق على الصفوف القديمة بصمت لمجرد أن النظام الجديد أصبح يملك حالة تم التحقق منها.
وهذا هو الفرق بين الترحيل وإعادة كتابة التاريخ.
مُهيأ لا يعني قيد التشغيل
هذا الحد جزء من الخدمة التي سأقدمها إلى فريق آخر.
قد يكون صندوق البريد موجوداً. وقد تكون أداة Turnstile موجودة. وقد تكون أسماء أسرار Worker مُهيأة. وقد تنجح الاختبارات. لا يعني أي من ذلك أن الموقع العام يشغّل قائمة الانتظار الجديدة بعد.
في التنفيذ المرجعي الحالي، تم تنفيذ تدفق الاشتراك المزدوج والتحقق منه محلياً. ولا تزال عملية ترحيل D1 المعلقة، وإصدار Worker الجديد، وCron التنظيف المجدول بحاجة إلى موافقة الإصدار والنشر. ولا يزال الموقع العام يشغّل نموذج قائمة الانتظار القديم إلى أن يحدث ذلك.
يحمي هذا التمييز النشاط التجاري. إذ تغيّر عملية ترحيل D1 شكل بيانات الإنتاج. ويغيّر نشر Worker سلوك التسجيل. ويضيف Cron تعديلاً في الخلفية. ويحتاج كل إجراء إلى نافذة إصدار صريحة، وتحقق، وتفكير في التراجع.
لا ينبغي شحن قائمة انتظار آمنة بشكل عابر لمجرد أن كلمة "آمنة" مرفقة بها.
كيف يبدو التحقق
عند تسليم قائمة انتظار جاهزة للإنتاج، أريد دليلاً قبل الإطلاق.
اجتاز التنفيذ المرجعي 150 اختباراً. وأبلغ Astro check عن 0 أخطاء. ونجح بناء الإنتاج. وكان العمل خاصاً بالويب، لذلك تُركت التغييرات الحالية في التطبيق الأصلي من دون تعديل.
ولا تزال قائمة التحقق من الإصدار مهمة بعد ذلك:
هذا هو الفرق بين "الكود يُبنى بنجاح" و"قمع التسجيل جاهز لاستقبال الزيارات".
أين يفيد هذا الشركات الناشئة
يفيد هذا النمط عندما يكون الفريق قريباً من الإصدار التجريبي لكنه غير مستعد بعد للحسابات الكاملة.
قد تكون بصدد إطلاق تطبيق جوال، أو أداة SaaS، أو إصدار ألفا خاص، أو ميزة AI مقيدة، أو قائمة حجز لأجهزة. أنت بحاجة إلى جمع الطلب، لكنك تحتاج أيضاً إلى بيانات نظيفة وموافقة قبل أن تبدأ في إرسال الدعوات.
تمنحك قائمة انتظار آمنة على Cloudflare ذلك من دون إضافة خلفية كبيرة:
إنه صغير بما يكفي لشحنه بسرعة، وصارم بما يكفي للوثوق به.
هل تحتاج إلى هذا لمنتجك؟
يمكنني المساعدة في تصميم تدفق التسجيل هذا لفرق المنتجات، أو تأمينه، أو تنفيذه.
لا يكمن العمل المفيد في وضع CAPTCHA على نموذج. بل في تحديد معنى التسجيل، وكيفية إثبات الموافقة، ومكان تخزين الرموز، وكيفية تسليم البريد الإلكتروني، وما يراه المسؤولون افتراضياً، وكيفية التحقق من الإصدار قبل وصول الزيارات العامة إليه.
إذا كانت قائمة الإصدار التجريبي الخاصة بك على وشك أن تصبح جزءاً من خطة الإطلاق، فمن المفيد جعل القائمة موثوقة قبل استخدامها لاتخاذ القرارات.