المصادقة باستخدام مفاتيح API عند الوصول إلى الـ API عبر fetch

مرحبًا!

أقوم ببناء موقع ووردبريس بدون واجهة أمامية (headless) لمجلة، ولديهم مجتمعهم على Discourse، ويتم دمج التعليقات في صفحات المقالات. لقد وجدت وثائق الـ API وسعدت جدًا، حيث أن تضمين iframe لم يكن ما كنت أبحث عنه حقًا، لأن الموقع سيحتوي على وضع ليلي ونهاري، لذا أحتاج إلى قالب التعليقات ليرث متغيرات CSS من العنصر الجذر.

ومع ذلك، أستمر في الوصول إلى حد معدل الطلبات (rate limit) عند محاولة الوصول إلى الـ API مباشرة (باستخدام fetch على https://discourseurl.com/t/{id}.json)، لذا فكرت في تجربة إضافة مفتاح API والمصادقة باستخدامه.

أستخدم هذا الكود:

fetch(this.apiUrl, {
        headers: {
          'User-Api-Key': '{مفتاح API الخاص بالمستخدم من لوحة تحكم Discourse}',
        },
      })

وأحصل على هذه الرسالة، بغض النظر عن المفتاح الذي أستخدمه (حتى عند تجربة مفتاح المسؤول):

error_type: "invalid_access"
errors: Array [ "Du har inte behörighet att visa den efterfrågade resursen." ]

تقريبًا الترجمة: “ليس لديك صلاحية لعرض المورد المطلوب”.

هل هناك شيء أفتقده فيما يتعلق بكيفية عمل مفاتيح الـ API؟ ما هو النهج الموصى به لطلب نقاط نهاية الـ API هذه دون الوصول إلى حد معدل الطلبات؟

راجع قسم المصادقة الموجود في الجزء العلوي من https://docs.discourse.org/. يقدم هذا القسم مثالًا على كيفية تعيين بيانات اعتماد واجهة برمجة التطبيقات (API) في رأس الطلب. يجب استخدام Api-Key و Api-Username في الرأس.

شكرًا لك! لا أستطيع أن أتخيل كيف فاتني جزء المصادقة هناك، لقد كنت أبحث في الوثائق مرارًا وتكرارًا :joy:

على أي حال، يبدو أنني أحرز بعض التقدم، لكنني أواجه هذه المشكلة الآن في وحدة تحكم المتصفح:
(Reason: missing token 'api-key' in CORS header 'Access-Control-Allow-Headers' from CORS preflight channel).

لا أعرف ما الذي قد يكون سببها، ولم أجد أي شيء في المنتدى عنها أيضًا. هل فاتني شيء؟ الغريب أنني أقوم بتعيين الرأس في كودي باسم ‘Api-Key’. أي أفكار؟ :slight_smile:

يبدو أنك تبني تطبيقًا بلغة جافا سكريبت وتقوم بإجراء طلبات API من المتصفح؟

النهج الموصى به هو إجراء استدعاءات API إلى سيرفر Discourse من جانب الخادم (server-side)، وجعل تطبيق جافا سكريبت الخاص بك يتواصل مع سيرفرك بنفس الطريقة التي يتواصل بها مع ووردبريس. بهذه الطريقة تتجنب أي مشاكل CORS.

آه، رائع! هذا جعلني أراجع كود WP Discourse وأدرك أنني على بعد خيار واحد فقط من جعل ووردبريس يعرض نقطة نهاية الـ API التي أحتاجها (عرض تعليقات Discourse عبر واجهة برمجة التطبيقات). سأقوم فقط بضبطها قليلاً. هذا ممتاز، شكرًا جزيلاً :slight_smile:

فقط بدافع الفضول، لماذا لا يُنصح بالعمل مباشرة مع واجهة برمجة تطبيقات Discourse من جانب العميل؟ لدي بعض الأفكار لتوسيع المشروع لاحقًا إذا توفر ميزانية (مع وظيفة تسجيل الدخول، على سبيل المثال)، وأود أن يتواصل مع واجهة برمجة تطبيقات Discourse. هل سأضطر لتوجيه كل شيء عبر ووردبريس؟ :slight_smile: