أواجه مشكلة في تضمين Discourse في موقع الشبكة الداخلية الخاص بنا.
توضح وثائق واجهة برمجة التطبيقات (API) أن طلبات Discourse تتطلب وجود رؤوس “API-Key” و “Api-Username” للمصادقة والحصول على الوصول إلى التغذية. ومع ذلك، فإن فحص ما قبل التحميل (Pre-flight check) يشير إلى أن القيم المسموح بها هي “User-API-Key” و “User-Api-Client-Id”.
عند استدعاء الواجهة دون استخدام متصفح، تعمل الأمور كما هو متوقع. لكن عند الاستدعاء عبر المتصفح، يزعم الخادم أنه يتطلب “User-API-Key” و “User-Api-Client-Id”.
لقد تحققت من أن الاتصال الأساسي يعمل باستخدام PostMan، ويتصرف هذا الأداة وفقًا لوثائق Discourse.
إذا قمنا بتمرير الرؤوس المذكورة في الوثائق، فإن المتصفح يحجب الطلب بسبب فحص ما قبل التحميل ويظهر خطأ CORS متعلق بـ “Access-Control-Allow-Headers”.
أما إذا قمنا بتمرير الرؤوس التي يقبلها الخادم، فإننا نحصل على خطأ “غير مصرح به” لأن التطبيق يتوقع قيمًا بأسماء مختلفة.
لقد حاولت إضافة الرؤوس إلى إعدادات Docker، لكن يبدو أنها لا تُطبَّق. لقد تم تمكين CORS في الإعدادات، وتم تعيين الأصل (origin) إلى “*”.
لدينا نظامان مختلفان لمصادقة API، مما قد يكون مربكًا.
هذه مخصصة لـ ‘admin API’، والذي يُوصف في docs.discourse.org. لم يُصمم هذا للاستخدام من قبل عملاء JavaScript.
هذه تأتي من مواصفات “User API”، والتي يمكن استخدامها من عميل JavaScript (وبالتالي تدعم CORS). هناك تفاصيل أكثر حول هذا هنا: User API keys specification
@david أنا أستخدم SSO وأريد تسجيل خروج المستخدم من Discourse عند تسجيل خروجه من التطبيق. حالياً أستخدم ‘واجهة برمجة التطبيقات للمسؤول’ لجلب معرف المستخدم عبر /users/by-external/${id}.json، لكنني أواجه أخطاء CORS. لا أرغب في تمكين ‘واجهة برمجة التطبيقات للمستخدم’ لكل مستخدم فقط لعملية تسجيل الخروج هذه. ما الذي تقترحه؟
نعم، إنه جافا سكريبت في تطبيقي. أفهم ذلك. إذن ما البديل؟ هل يمكنني إضافة ‘واجهة برمجة تطبيقات مستخدم’ لمستخدم واحد واستخدامها لإجراء المكالمة لجميع المستخدمين؟
إذا كنت تستخدم واجهة برمجة التطبيقات للمستخدم، فيجب أن يتم ذلك لكل مستخدم على حدة. لا يجب مشاركة المفاتيح.
لكن الأكثر شيوعًا هنا هو التعامل مع الأمر من جانب الخادم في تطبيقك. يمكن للخادم إرسال طلب باستخدام مفاتيح واجهة برمجة التطبيقات الخاصة بالمسؤول دون مشاكل تتعلق بـ CORS، ومع مخاوف أمنية أقل (طالما تم تنفيذه بشكل آمن).
مرحبًا @david، لقد حاولت تنفيذ حل في الخلفية، ولكن عند استدعاء https://example.com/users/by-external/{EXTERNAL_USER_ID}.json?api_key={DISCOURSE_API_KEY}&api_username=system، تكون الاستجابة التي أحصل عليها هي صفحة تسجيل الدخول (أظن أنها تعيد التوجيه إليها). لقد تم تمكين خيار “تسجيل الدخول مطلوب”، وعندما أقوم بتعطيله، أحصل على استجابة JSON صحيحة. أريد الإبقاء على هذا الإعداد مفعلًا - هل لديك أي أفكار حول ما يحدث؟
