Skip to main content
يُخبر كائن auth المنصة كيف يربط المستخدمون حساباتهم بخدمتك. يتحكم auth.type في تجربة التثبيت (نموذج bearer_token / apikey مقابل نافذة منبثقة لـ oauth2). أما كيفية إرسال بيانات الاعتماد في كل استدعاء HTTP فتُعرَّف في ترويسات الطلب (Bearer أو Basic أو ترويسات مخصصة أو معاملات استعلام).

Bearer Token (مفتاح API)

أبسط طريقة مصادقة. يلصق المستخدم مفتاح API الخاص به في نموذج، وتخزّنه المنصة بأمان.
كيف تعمل:
  1. يُدخل المستخدم مفتاح API في نموذج الإعدادات
  2. تستدعي المنصة طفرة saveMiniAppCredentials
  3. إذا عُرِّف get_token، يُنفَّذ لتبادل/التحقق من بيانات الاعتماد
  4. تُخزَّن الرموز والأسرار في InstalledMiniApps.credentials
  5. إذا عُرِّف userDetails، تُخزَّن حقول المتجر/الحساب المُعيَّنة في InstalledMiniApps.metadata
  6. تُضبط الحالة إلى connected

مصادقة HTTP Basic

استخدمها عندما يتوقع المزوّد Authorization: Basic <base64(username:password)> — شائعة في WooCommerce (Consumer Key + Consumer Secret)، وبوابات الدفع (مثل Moyasar)، وبعض واجهات البرمجة القديمة. عرّف الترويسة بنقطتين حرفيتين : بين نائبي بيانات الاعتماد. يقوم وقت التشغيل بترميز Base64 لـ user:pass تلقائياً بعد حلّ العناصر النائبة (لا يحتوي Base64 على :، لذا تُترك القيم المرمَّزة مسبقاً كما هي).
استخدم الترويسة نفسها في كل طلب إجراء / مصدر / مزامنة:
ملاحظة النشر — يعمل الترميز التلقائي لـ Basic داخل miniAppsReplaceVariablesInObject لأي ترويسة Authorization. انشر plugin-miniapps-api مع هذا المساعد قبل شحن بذور بأسلوب WooCommerce؛ وإلا تُرسل السلسلة الخام key:secret ويعيد المزوّدون 401.
نصيحة WooCommerce: فضّل HTTPS + Basic. إذا أزال المضيف ترويسة Authorization، فالرجوع إلى معاملات الاستعلام (consumer_key / consumer_secret) على ذلك الطلب — راجع بذرة WooCommerce.

رموز الترويسة المخصصة

بعض المزوّدين يستخدمون ترويسة مخصصة بدل Bearer/Basic (مثل Shopify X-Shopify-Access-Token، وTikTok Access-Token):
تبقى تجربة التثبيت auth.type: 'apikey' (أو bearer_token) مع نموذج للرمز وأي حقول لنطاق المتجر.

تخزين التثبيت لكل مستأجر

كل ميني أب مثبَّت يحتفظ بثلاث حقائب من جانب الخادم على InstalledMiniApps: يُحلّ [[key]] من credentials أولاً، ثم metadata (تفوز credentials عند تصادم المفاتيح). استخدم مفاتيح camelCase في التعيينات (مثل storeId) حتى عندما يختلف اسم ترويسة HTTP (Store-Id: '[[storeId]]').

OAuth 2.0

للخدمات التي تتطلب تفويض OAuth 2.0 (Salla وGoogle وغيرها).
تدفق OAuth 2.0:

تحديث الرمز

عندما يُضبط auto_refresh: true ويعيد أي طلب إجراء استجابة 401:
  1. تستدعي المنصة تلقائياً طلب refresh_token
  2. تُستخرج بيانات الاعتماد الجديدة عبر التعيين
  3. تُحدَّث بيانات الاعتماد في قاعدة البيانات
  4. يُعاد محاولة الطلب الأصلي الفاشل بالرمز الجديد
يُعالَج هذا بشفافية — دون تفاعل من المستخدم.

طلبات التسجيل (إعداد ما بعد المصادقة)

طلبات التسجيل هي استدعاءات API تُنفَّذ مرة واحدة مباشرة بعد مصادقة المستخدم بنجاح. استخدمها لـ:
  • تسجيل الويب هوك لدى المزوّد
  • جلب الإعداد الأولي (معرّف المتجر، معلومات مساحة العمل)
  • الاشتراك في الأحداث
العناصر النائبة المتاحة في طلبات التسجيل:
تعيينات الكائنات في registrationRequests تُحفظ في credentials. تعيينات userDetails تُحفظ في metadata بالكامل. كلتا الحقيبتين متاحتان لعناصر [[key]] النائبة في ترويسات المزامنة والإجراءات والأتمتة.
آخر تعديل في ٨ أغسطس ٢٠٢٦