إضافة حقل domain إلى جدول العملاء ليست ميزة دومينات مخصّصة مكتملة. الربط يمر بإثبات ملكية وتهيئة DNS وشهادة TLS وتوجيه صحيح. قد تنجح مرحلة وتفشل أخرى؛ لهذا يجب أن يعبّر النظام عن الحالة الفعلية بدل زر يعطي «تم الربط» بمجرد حفظ الاسم.
افصل الحالات بوضوح
استخدم دورة مثل pending_verification ثم pending_dns ثم pending_certificate ثم active، مع حالة failed قابلة للتشخيص. هذه أسماء تصميمية يمكن تكييفها، وليست حالات مفروضة من كل مزوّد. خزّن وقت آخر فحص وسبب الفشل دون عرض تفاصيل داخلية لا تفيد المستخدم. امنع العميل من إدخال عنوان كامل بمسار؛ الحقل يحتاج hostname مضبوطًا ومطبّعًا.
أثبت حق الاستخدام قبل التوجيه
وجود طلب لإضافة example.com لا يثبت أن صاحبه يتحكّم به. أنشئ تحدّي تحقق وفق المزوّد، واربط الدومين بعميل واحد باستخدام قيد فريد. لا تنسخ رموز إثبات بين العملاء، ولا تعتبر سجلات DNS قديمة إثباتًا دائمًا. وثائق Cloudflare تفرّق بين التحقق من hostname والتحقق اللازم لإصدار الشهادة؛ نجاح أحدهما لا يساوي نجاح الآخر.
عامل DNS وTLS كعمليتين مستقلتين
اعرض السجلات الدقيقة التي يعيدها مزوّد الاستضافة، بدل افتراض أن كل دومين يحتاج نفس A أو CNAME. افحص الوجهة وحالة الشهادة قبل إعلان التفعيل. إعادة الفحص المتباعدة أفضل من طلبات سريعة متكرّرة، مع حد للمحاولات وزر واضح لإعادة المحاولة. يجب أن تبقى لوحة الإدارة على نطاق موثوق حتى لو كان دومين العميل معطّلًا.
Claim hostname -> verify ownership -> check DNS target
-> validate certificate -> activate routing
Remove hostname -> stop routing -> release provider binding
وجّه الطلب من سجل موثوق
طبّع hostname ثم ابحث عنه في ربط فعّال ومعروف. لا تستخرج tenant_id من أي Host عشوائي، ولا تثق بترويسات forwarded إلا ضمن إعداد proxy موثوق. اسم غير معروف يجب أن ينتهي باستجابة واضحة، لا ببيانات عميل افتراضي. اختبر الدومين الأساسي وwww؛ هما اسمان مختلفان ويحتاجان قرار ربط أو تحويل مقصودًا.
راجع الجلسات والروابط والنسخ المتكررة
تغيير النطاق يؤثّر في cookies وOAuth redirects وروابط البريد. تجنّب توسيع نطاق cookie بلا حاجة، وحدّد أين يعيش تسجيل الدخول. للصفحات العامة المتكررة على نطاق المنصة والدومين المخصّص، اختر عنوانًا أساسيًا consistent canonical وتحويلات مناسبة إذا كان ذلك متوافقًا مع المنتج. لا تطبّق تحويلًا شاملًا على API أو webhooks دون مراجعة العقود.
الإزالة جزء من الميزة
عند إلغاء الربط، أوقف التوجيه وامسح ارتباط المزوّد، وتعامل مع بقايا DNS لدى العميل. إعادة ربط نفس الاسم لاحقًا تحتاج تحققًا جديدًا حسب سياسة النظام. اختبر انتهاء الشهادة، وتغيّر DNS، وتعطّل المزوّد، وخروج العميل من الخدمة. الميزة الموثوقة لا تكتمل عند أول ظهور ناجح للصفحة، بل عندما تكون حالات التعطّل والخروج مفهومة وقابلة للإدارة.
سيناريو عملي: DNS صحيح والشهادة معلّقة
عندما يشير الدومين إلى الوجهة المطلوبة ولا تزال الشهادة معلّقة، يجب أن تشرح الواجهة أن التوجيه والشهادة مرحلتان مختلفتان. اعرض نتيجة آخر فحص ومتطلّبات المزوّد الفعلية، ولا تطلب من العميل إعادة تغيير سجل صحيح بلا دليل. أبقِ النطاق غير نشط داخل التطبيق حتى تتحقق الشروط المطلوبة، مع توفير عنوان المنصة المؤقت للوصول إلى المنتج.
تجربة نقل الدومين بين عميلين
اختبر حذف الربط من حساب قديم ثم طلبه من حساب جديد. يجب ألا يكفي وجود سجل DNS متروك لاسترجاع بيانات الحساب الأول أو تجاوز سياسة التحقق الجديدة. راجع الكاش المستخدم لتوجيه الدومينات ومتى يُبطَل بعد الحذف. جرّب طلبات متزامنة أثناء الانتقال، وتأكد أن النطاق غير المعروف لا يصل إلى عميل افتراضي أو صفحة تحمل بيانات الحساب السابق.
المراجع الرسمية
تدعم هذه المراجع سلوك الأدوات المذكورة. الأمثلة وقرارات التصميم توضيحية، ويجب تكييفها مع متطلبات المشروع وإصداراته.
إعداد: Noor Yasser
تعمل على تحدٍ تقني مشابه؟
أساعد الفرق على تحويل القرار المعماري إلى نطاق واضح وتنفيذ يمكن تشغيله ومراجعته بثقة.
