مصادقة Composer لمستودعات Magento الخاصة: الإعداد الذي يعمل

تتخطى معظم أدلة تثبيت وحدات Magento خطوة مصادقة Composer. ثم يواجه المطور خطأ 401 غير مصرح عند استخدام composer require، ويبحث في جوجل لمدة ساعة، وينتهي به المطاف هنا.

هذا هو الإعداد الذي يعمل، مكتوب من سير العمل الذي نستخدمه في مئات التثبيتات.

نموذج الرمزين

تحتاج Magento إلى مجموعتين من بيانات الاعتماد المكونة في Composer:

1. بيانات اعتماد Adobe Commerce لـ repo.magento.com. السجل الخاص بـ Adobe الذي يحتفظ بحزم Magento الأساسية.
2. بيانات اعتماد خاصة بالمورد لأي سجل خاص تابع لجهة خارجية. على سبيل المثال، سجل مورد وحدتك.

تحتاج إلى كلاهما. تأتي بيانات اعتماد Adobe من حساب Adobe Commerce الخاص بك. تأتي بيانات اعتماد المورد من المورد مع بريد تسليم الطلب.

أين تعيش بيانات الاعتماد

هناك موقعان مهمان.

لكل مشروع: auth.json في جذر المتجر.

{
  "http-basic": {
    "repo.magento.com": {
      "username": "your-public-key",
      "password": "your-private-key"
    },
    "repo.example-vendor.com": {
      "username": "your-customer-id",
      "password": "your-license-key"
    }
  }
}

عالمي: ~/.composer/auth.json على جهاز المطور. نفس الشكل. يقرأ Composer ملف المشروع أولاً، ثم يعود إلى العالمي.

لإنتاج: احتفظ ببيانات الاعتماد في متغيرات البيئة وقم بتهيئة auth.json في وقت النشر. لا تقم أبداً بإدخال auth.json في المستودع. يبدو أن هذا بديهي. لكنه أيضاً الخطأ الأكثر شيوعاً الذي نراه.

كتلة المستودعات

في composer.json تحت repositories، أضف سجل المورد:

{
  "repositories": {
    "magento": {
      "type": "composer",
      "url": "https://repo.magento.com/"
    },
    "example-vendor": {
      "type": "composer",
      "url": "https://repo.example-vendor.com/"
    }
  }
}

ترتيب الأمور مهم. يقوم Composer بمسح المستودعات بالترتيب المعلن. إذا قدمت سجلاتان نفس اسم الحزمة، فإن الأولى تفوز.

أوضاع الفشل الثلاثة

عندما يفشل composer require، يكون السبب غالباً أحد هذه الأسباب.

1. نوع الرمز خاطئ. زوج المفتاح العام مع المفتاح الخاص من Adobe يذهب إلى repo.magento.com فقط. إذا قمت بلصقها في خانة سجل المورد، فإن المورد يستجيب بخطأ 401. الحل: تحقق مرة أخرى من أي بيانات اعتماد تنتمي إلى أين.

2. عنوان URL للسجل قد تغير. يقوم الموردون أحياناً بترحيل مجالات السجل. قد يكون ملف composer.json الخاص بك الذي مر عليه ستة أشهر يشير إلى عنوان URL القديم، الذي يقدم الآن إعادة توجيه لا يتبعها Composer. الحل: تحقق من الوثائق الحالية للمورد للحصول على عنوان URL للسجل.

3. جدار الحماية يمنع الوصول إلى السجل. قد لا تتمكن خوادم الإنتاج في بيئات الشبكة المقيدة من الوصول إلى repo.example-vendor.com. الحل: أضف مجال السجل إلى قائمة السماح بالخروج. بعض الموردين يقدمون عنوان IP ثابت لهذا.

النسخة الخاصة بـ CI

في CI، نمط العمل هو:

COMPOSER_AUTH='{"http-basic":{"repo.magento.com":{"username":"'"$MAGENTO_USERNAME"'","password":"'"$MAGENTO_PASSWORD"'"}}}' composer install

قم بتمرير بيانات الاعتماد عبر متغيرات البيئة، وابنِ JSON في السطر، ثم قم بتشغيل التثبيت. لا يوجد ملف على القرص، ولا خطر من الالتزام غير المقصود.

تدوير الرموز

قم بتدوير الرموز كل ثلاثة أشهر. معظم الموردين يقدمون زر "إعادة توليد" في إعدادات حسابك. بعد التدوير:

1. تحديث ~/.composer/auth.json على كل جهاز مطور وCI runner.
2. تحديث الأسرار الإنتاجية في خط أنابيب النشر.
3. قم بتشغيل اختبار composer install في كل بيئة للتأكيد.

إذا تسرب رمز (التزام غير مقصود، لقطة شاشة في تذكرة خطأ، طرف ثالث يرى وحدة التحكم الإنتاجية)، قم بالتدوير على الفور وراجع سجل الوصول إذا كان المورد يقدم واحداً.

عندما يفشل هذا أيضاً

إذا كنت قد تحققت من كل ما سبق وما زال Composer يرفض المصادقة، اطلب من المورد فحص سجلات خادمهم لعنوان IP الخاص بك. أحياناً يخفي الخطأ 401 خطأ 403 من قاعدة WAF أضافها مزود استضافة المورد دون إخبارهم. لقد قمنا بتصحيح هذه الحالة بالذات ثلاث مرات في العام الماضي.