أعمالنا · دراسة حالة
اللوحة التي تدير منظومة هويتك ينبغي أن تكون أوضح شاشة فيها.
01 / التحدي
كانت منصة إدارة هوية ووصول مفتوحة المصدر تملك لوحة إدارة قديمة بمسارات تهيئة غير متّسقة ورؤية ضعيفة لسجلات المصادقة. وهذه ليست مشكلة شكلية في منتج أمني: فالمشرف الذي لا يرى ما جرت مصادقته، أو الذي يهيّئ خادماً بطريقتين مختلفتين على شاشتين، هو ثغرة امتثال. وبشكل منفصل، كان تسجيل FIDO2 يُرجع أخطاء 400 تتباين حسب البيئة.
02 / المقاربة
رُحِّلت اللوحة إلى تايب سكربت بنيوياً لا ملفاً ملفاً. أُدخلت الأنواع حيث تعبر مسارات التهيئة واجهة Config API، لأن هناك يتحوّل الشكل الخاطئ إلى إعداد خادم خاطئ، وأُعيد بناء طبقة المكوّنات القابلة لإعادة الاستخدام ليُعرض العنصر نفسه بالطريقة نفسها أينما ظهر الإعداد.
وعوملت رؤية سجلات المصادقة كشاشة أساسية لا كأثر جانبي للتنقيح. ووُحّدت معالجة التهيئة عبر الأسطح التي تلامس خادم المصادقة وSCIM وFIDO2 وأغاما وكازا وغيرها، فيقرأ المشرف قواعد واحدة عبر المنظومة.
وتبيّن أن أعطال FIDO2 كانت تبايناً بين ما تتوقّعه الخلفية وما يرسله متصفّح حقيقي فعلاً. وبدل الاستدلال من المواصفة، التقطنا استجابات تسجيل WebAuthn حقيقية من المتصفّح وواءمنا حمولات التحقق وفحوص rp.id معها، ثم بنينا اختبارات تكامل واختبارات تحكّم من تهيئات خادم فعلية كي لا يعود الانحراف نفسه بصمت.
03 / النتيجة
أشهر من التسليم المتواصل
بيئتا نشر: كوبرنيتس وأجهزة افتراضية
صارت اللوحة أسهل صيانة بصورة ملموسة — إذ التقط تايب سكربت صنفاً من الأخطاء كان يصل سابقاً إلى خادم يعمل، وصارت عمليات البناء أسرع، والتحقق على مستوى النماذج متّسقاً عبر شاشات التهيئة. واستقرّ تسجيل FIDO2 والمصادقة عبر البيئات، بتغطية اختبارية لنقطتي التسجيل والتحقق تحاكي سلوك الخادم الحقيقي لا مثالاً مُحاكى.