تمكنت من جعل هذا يعمل بعد بعض التجربة والخطأ.
إليك الخطوات الأساسية التي أتبعها عندما يكون لدي تطبيق منفصل قمت ببرمجته، وأريد أن يتمكن المستخدمون من استخدام هذا التطبيق لإجراء استدعاءات API إلى موقع Discourse.
لنفعل ذلك، أحتاج إلى إنشاء رمز API خاص بكل مستخدم لإجراء الاستدعاءات نيابة عن كل مستخدم محدد (على الأقل في بيئة Node.js/JavaScript).
ملاحظة: بالنسبة لجهة JavaScript، وجدت أن الكود الذي قدمه @KengoTODA هنا مفيد جدًا: discourse-api-key-generator/src/index.ts at main · KengoTODA/discourse-api-key-generator · GitHub
إليك الخطوات التي اتبعتها:
أولاً: توليد زوج من المفاتيح العامة والخاصة.
هذا شيء يجب أن يولده تطبيقك — مفتاح عام ومفتاح خاص. توفر ملخص GitHub (Gist) طريقة واحدة للقيام بذلك.
ثانياً: وجود عنوان URL لإعادة التوجيه.
هذا هو عنوان URL الذي سيعيد Discourse التوجيه إليه، مع توفير رمز API النهائي في الحمولة (payload). إذا كان لديك تطبيق سطح مكتب (أي لا يحتوي على عنوان URL للمتصفح)، فسيكون عنوان URL لإعادة التوجيه قائمًا على بروتوكول مخصص قمت بإعداده لفتح التطبيق عند إدخال عنوان URL لإعادة التوجيه في المتصفح.
لاحظ أن عنوان URL لإعادة التوجيه يجب أن يُدرج في القائمة البيضاء في إعدادات الموقع لموقع Discourse المستهدف.
كما يحتاج موقع Discourse على الأرجح إلى تفعيل إعداد الموقع “السماح بمفاتيح API للمستخدمين”. راجع المنشور الأصلي في هذا الموضوع بخصوص “إعدادات الموقع”.
ثالثاً: إرسال استدعاء طلب API إلى عنوان URL لطلب Discourse.
لذا، سيقوم تطبيقك بإرسال استدعاء إلى عنوان URL يتبع هذا الشكل:
https://[your target discourse site .com]/user-api-key-new"
مع إضافة المعاملات التالية:
- اسم تطبيقك
- “client_id” الخاص بك (تمكنت من استخدام hostname()، من
const {hostname} = require('os')لتطبيق سطح المكتب، تمامًا كما في ملخص GitHub المشار إليه أعلاه) - النطاقات (scopes) (هذه هي النطاقات التي تريد أن يتمكن المستخدم من القيام بها عبر API، مثل “write”، “read”، إلخ)
- مفتاحك العام (من الخطوة 1 أعلاه)
- عنوان URL لإعادة التوجيه الخاص بك (من الخطوة 2 أعلاه)
- nonce (هذه قيمة يمكنك اختيارها — يبدو أن استخدام ‘1’ فقط يعمل)
رابعاً: موافقة المستخدم على تطبيقك في صفحة موقع Discourse التي يتم فتحها بواسطة عنوان URL للطلب.
عند إرسال عنوان URL للطلب بنجاح، يفتح صفحة على موقع Discourse تخبر المستخدم بأن تطبيقك يريد الوصول إلى الموقع.
في تلك الصفحة، يوجد زر يسمح للمستخدم بالموافقة. عند النقر على هذا الزر، يعيد موقع Discourse التوجيه إلى عنوان URL لإعادة التوجيه الذي قدمته، ويضيف كمعامل ?payload=[the API KEY]. مفتاح API هنا هو المفتاح الذي تحتاج إلى فك تشفيره في تطبيقك.
خامساً: يلتقط تطبيقك قيمة عنوان URL لإعادة التوجيه (مع قيمة الحمولة)، وتقوم بفك تشفير مفتاح API.
لقد اقتربت من النهاية. يحتاج تطبيقك إلى تحليل عنوان URL لإعادة التوجيه الذي انتقل إليه Discourse، والحصول على مفتاح API الموجود في الحمولة.
بمجرد حصولك على مفتاح API هذا، تحتاج إلى القيام بأمرين:
- احصل على المفتاح الفعلي، وليس النسخة المشفرة URL: إذا كنت تحصل على معامل من عنوان URL، فغالبًا ما يكون مشفرًا URL (إضافة % هنا وهناك، إلخ). تحتاج إلى تنظيفه. في JavaScript، وجدت أن
decodeURIComponentتعمل لهذا الغرض. - بمجرد استلامك لمفتاح API المنقى من Discourse، تحتاج إلى فك تشفيره. للقيام بذلك، يمكنك استخدام فك التشفير في JavaScript باستخدام المفاتيح الخاصة. أساسًا، تستخدم مفتاحك الخاص (المُولد في الخطوة الأولى أعلاه) لفك تشفير مفتاح API المنقى. هناك بعض أمثلة JavaScript في ملخص GitHub الذي أشرت إليه أعلاه: discourse-api-key-generator/src/index.ts at main · KengoTODA/discourse-api-key-generator · GitHub
بعد تشغيل كود فك التشفير، يكون لديك الرمز نفسه، والذي يمكنك الآن استخدامه لإجراء استدعاءات API مصادق عليها نيابة عن المستخدم.
سادساً: استخدم الرمز (أي مفتاح API النهائي، المنقى، وفك تشفيره) لإجراء استدعاءات API نيابة عن المستخدم.
مع هذا الرمز، يبدو أنك لا تحتاج إلى إدخال اسم المستخدم في استدعاء API. أجد أن العنوان التالي كافٍ عند تضمينه في استدعاءات GET أو POST أو PUT، إلخ:
headers: {
"User-Api-Key": [the token]
}
وبذلك، يكون لديك على الأرجح طريقة مصادقة لكل مستخدم تعمل للتفاعل مع Discourse.