كيف قمنا ببناء بروكسي مصادقة Composer الذي يخدم وحدات Magento الخاصة بنا
كل وحدة من وحدات eTechFlow يتم تثبيتها عبر Composer من مستودع خاص على repo.etechflow.com. المستودع محمي ببيانات اعتماد خاصة بكل عميل تتوافق مع حق ترخيص محدد. هذه المقالة تتناول الهندسة وراء ذلك: بروكسي المصادقة، دورة حياة البيانات الاعتمادية، ووضعيات الفشل التي صممناها.
المشكلة التي احتجنا إلى حلها
عندما يشتري عميل وحدة Magento منا، يحتاج إلى القيام بشيئين لتثبيتها. أولاً، إضافة مستودع Composer الخاص بنا إلى ملف composer.json الخاص بهم. ثانياً، المصادقة ضد ذلك المستودع باستخدام بيانات اعتماد تعمل لهم فقط.
معظم بائعي وحدات Magento يحلون هذه المشكلة باستخدام بيانات اعتماد مشتركة لكل بائع (كل من يشتري من Amasty يستخدم مجموعة واحدة من بيانات اعتماد Amasty) أو باستخدام بيانات اعتماد قائمة على البريد الإلكتروني (بريدك الإلكتروني ورقم الطلب). كلاهما له مشاكله. لا يمكن إلغاء بيانات الاعتماد المشتركة عندما يتم استرداد الترخيص. تتسرب بيانات اعتماد البريد الإلكتروني من خلال لقطات الشاشة وتقارير الأخطاء.
كنا بحاجة إلى بيانات اعتماد مرتبطة بالترخيص، قابلة للإلغاء، قابلة للتدوير، وقابلة للتدقيق.
الهندسة المعمارية
ثلاثة مكونات تتعامل مع المصادقة على كل تثبيت.
المكون 1: بروكسي المصادقة. خدمة Node صغيرة أمام مستودع Composer الفعلي. كل طلب إلى repo.etechflow.com يمر عبر البروكسي أولاً. يقوم البروكسي بقراءة بيانات اعتماد المصادقة الأساسية HTTP من الطلب، ويبحث عنها في قاعدة بيانات التراخيص لدينا، ويقرر ما إذا كان سيسمح بالطلب.
المكون 2: قاعدة بيانات التراخيص. تخزن بيانات الاعتماد المرتبطة بمعرف الترخيص. تحتوي كل صف على معرف العميل، واسم الوحدة التي اشتراها، وزوج البيانات الاعتمادية (اسم المستخدم بالإضافة إلى كلمة مرور مشفرة باستخدام bcrypt)، وتاريخ الإصدار، وانتهاء الصلاحية الاختياري، وحالة الإلغاء، وطابع الزمن الأخير الذي تم التحقق منه.
المكون 3: سجل التدقيق. كل محاولة مصادقة (نجاح أو فشل) تكتب صفًا مع عنوان IP، وطابع الزمن، والحزمة المطلوبة، ومعرف الترخيص المتطابق. سجل التدقيق قابل للاستعلام ويشكل أساس تنبيه النشاط المشبوه.
تدفق الطلب الكامل على composer require etechflow/some-module:
- يرسل Composer مصادقة أساسية HTTP إلى بروكسي المصادقة.
- يبحث البروكسي عن زوج البيانات الاعتمادية في قاعدة بيانات التراخيص.
- إذا كانت صالحة ولم يتم إلغاؤها، يقوم البروكسي بإعادة توجيه الطلب إلى سجل Composer الداخلي.
- يعيد السجل الداخلي الحزمة المطلوبة.
- يسجل البروكسي النجاح ويعيد الاستجابة إلى Composer.
إجمالي زمن التأخير: أقل من 50 مللي ثانية لكل عملية جلب حزمة. يقوم تثبيت Composer النموذجي بجلب من 1 إلى 3 حزم منا، لذا فإن التأخير غير مرئي للعميل.
دورة حياة البيانات الاعتمادية
يتم إنشاء بيانات الاعتماد في وقت شراء الوحدة. يحصل بريد العميل الإلكتروني على زوج البيانات الاعتمادية بالإضافة إلى تعليمات التثبيت على الفور. ترتبط البيانات الاعتمادية بمعرف الترخيص، مما يعني أنه يتم إلغاؤها بشكل متزامن إذا قام العميل باسترداد المبلغ (نافذة استرداد 30 يومًا).
بعد 12 شهرًا، نقوم بإنهاء صلاحية البيانات الاعتمادية ونرسل بيانات اعتماد تجديد عبر البريد الإلكتروني. تستمر البيانات الاعتمادية القديمة في العمل لمدة 90 يومًا خلال نافذة الانتقال حتى يتمكن العملاء من تحديث auth.json الخاص بهم دون استعجال.
إذا كان العميل يشتبه في تسرب البيانات الاعتمادية (تم الالتزام بها في مستودع عام، تم التقاطها في تذكرة خطأ)، يمكنهم تدويرها من لوحة معلومات حسابهم. يؤدي التدوير إلى إلغاء البيانات الاعتمادية القديمة على الفور وإصدار واحدة جديدة.
وضع الفشل الذي بنيناه حوله
أكبر خطر واحد مع هذه الهندسة المعمارية هو عدم توفر بروكسي المصادقة. إذا تعطلت repo.etechflow.com، فإن كل عميل يحاول تثبيت أو تحديث وحدة سيفشل. لدينا ثلاث طبقات من الحماية:
التكرار الجغرافي. يعمل بروكسي المصادقة في منطقتين مع توجيه نشط-نشط. يتجاوز الانقطاع الإقليمي خلال 60 ثانية.
نسخ قاعدة البيانات للقراءة. تحدث عمليات البحث عن بيانات الاعتماد ضد نسخ القراءة مع تأخير نسخ يبلغ 10 ثوانٍ. تكتب (بيانات اعتماد جديدة، إلغاءات) إلى النسخة الرئيسية. تبقى المسارات القابلة للقراءة على قيد الحياة حتى في حالة فشل النسخة الرئيسية.
الانخفاض السلس. عندما تصبح قاعدة البيانات غير قابلة للوصول تمامًا، يتراجع البروكسي إلى ذاكرة تخزين مؤقت للبيانات الاعتمادية لمدة 60 دقيقة تحتفظ بآخر عملية بحث ناجحة. لا يزال العملاء الذين يقومون بالتثبيت خلال تلك النافذة ينجحون. تتوقف عمليات شراء الوحدات الجديدة حتى تتعافى قاعدة البيانات.
لقد تم تفعيل مسار الانخفاض السلس ثلاث مرات منذ الإطلاق. في كل مرة، أبلغ العملاء عن عدم وجود مشاكل.
ما ننشره للعملاء
يرى العملاء الهندسة بشكل غير مباشر من خلال ثلاث واجهات.
تخبرهم مقتطف auth.json في بريدهم الإلكتروني الخاص بالشراء بالضبط ما يجب إضافته إلى متجرهم. التنسيق هو مصادقة أساسية HTTP قياسية في الهيكل المتوقع من Composer، لذا يمكن لأي مهندس ملم بـ Composer قراءته.
تظهر لوحة معلومات الحساب جميع بيانات الاعتماد النشطة الخاصة بهم، ومتى تم إصدار كل منها، وزر تدوير بنقرة واحدة. لا نظهر قيمة كلمة المرور بعد الإنشاء؛ يولد التدوير واحدة جديدة.
سجل التدقيق داخلي فقط بشكل افتراضي. يمكن للعملاء طلب تصدير نشاط بيانات الاعتماد الخاصة بهم لمراجعات الأمان.
ما كنا سنفعله بشكل مختلف
خياران تصميم كنا سنعيد النظر فيهما إذا بدأنا من جديد.
كنا سنستخدم رموز حاملة HTTP بدلاً من المصادقة الأساسية. لقد دعمت Composer رموز الحامل لعدة سنوات الآن وهي أنظف للإلغاء دون كسر توقعات المثبت. اخترنا المصادقة الأساسية في البداية لأنها تعمل مع إصدارات Composer الأقدم؛ الإصدارات الأقدم نادرة الآن بما يكفي لنتمكن من الانتقال.
كنا سننظر في تدفق جهاز OAuth لتثبيت المرة الأولى. اليوم، يتعين على العميل لصق بيانات الاعتماد يدويًا في auth.json أو تشغيل أمر تكوين Composer. سيسمح تدفق جهاز OAuth بالموافقة على التثبيت من جلسة متصفح العميل. يضيف بنية تحتية ولكنه يقلل من الاحتكاك في التثبيت الأول.
لماذا هذا مهم لنظام Magento البيئي
لم يقم معظم بائعي وحدات Magento ببناء بنية تحتية مناسبة للبيانات الاعتمادية. النمط الشائع (بيانات الاعتماد المشتركة، الوصول المرتبط بالبريد الإلكتروني، عدم وجود سجل تدقيق) يخلق فجوات أمنية حقيقية. عندما يتم اختراق متجر Magento من خلال وحدة طرف ثالث، يكون سجل التدقيق الذي يعود إلى بنية توزيع البائع عادةً فارغًا لأنه لم تكن هناك بنية تحتية موجودة لتسجيلها.
إذا كنت تقوم بتقييم بائعي وحدات Magento، اسألهم كيف تعمل مصادقة Composer الخاصة بهم. تكشف الإجابة عن مدى جدية اهتمامهم بأمان سلسلة التوريد.
ذات صلة
- مصادقة Composer لمستودعات Magento الخاصة تغطي إعداد جانب العميل.
- دليل شراء ملحقات Magento يغطي معايير تقييم البائع.