نشر قسري في فئة مقيدة

مرحباً،

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

شكراً جزيلاً!

من غير المرجح أن يتم توثيق واجهة برمجة التطبيقات (API) لحالتك الخاصة لأنها غير مدعومة تمامًا (مع أن لدي عميلًا واحدًا على الأقل يقوم بشيء مشابه). يُعد دليل كيفية هندسة واجهة برمجة تطبيقات Discourse عكسيًا أفضل ما يمكنك الحصول عليه، وكذلك ملف discourse/config/routes.rb at main · discourse/discourse · GitHub.

إذا كنت تستخدم مفتاح واجهة برمجة تطبيقات إداري، فسيتم إزالة جميع القيود، وبالتالي يجب أن تتمكن من إنشاء الموضوع. أو ربما قم بإنشاء الموضوع باسم المستخدم ثم انقله إلى الفئة التي لا تريد أن يتمكن من النشر فيها؟

شكرًا لك. أنا أعرف عن الهندسة العكسية، لكن لا توجد حالة استخدام مماثلة من واجهة Discourse الأمامية يمكن اعتراضها. أقصد أنه، بينما أنا مسجل دخول كمسؤول، لا توجد طريقة لإنشاء موضوع باسم مستخدم آخر.

الحل البديل الذي طبقته حتى الآن هو السماح لجميع المستخدمين برؤية/التعليق على فئة محددة معينة، بينما يُسمح للمسؤولين بالرؤية/التعليق/الإنشاء. ثم يتم إنشاء المواضيع بواسطة “النظام” فقط (وبالتالي لا توجد طريقة للمستخدمين للتلاعب بالعناوين) مع وجود منشور أصلي كنموذج. بعد ذلك، يمكنني استخدام مفتاح الـ API للتعليق باسم مستخدمين مختلفين في تلك المواضيع المنشورة.

أعتقد أن المجموعة الأخرى التي كنت أساعدها كان لديها مستخدمون يسجلون الدخول إلى Discourse (ربما عبر SSO) بحيث يتصرفون باسمهم الخاص. بهذه الطريقة تحصل على جميع حماية المستخدمين التي يوفرها Rails. يبدو أن القيام بكل شيء بمفتاح واجهة برمجة تطبيقات إداري واحد هو وصفة للكوارث.

لكنني أظن أن ما ستفعله لحل مشكلتك الحالية هو إنشاء الموضوع باسم адin ثم تغيير ملكيته. يجب أن يكون ذلك أمرًا مباشرًا إلى حد ما. (ثم نأمل ألا يحدث أي خطأ بين بداية ونهاية المعاملة بأكملها.)

أظن أن احتمالًا آخر هو إنشاء مكون إضافي مخصص يضيف مسارًا لإنشاء موضوع باسم مستخدم معين (لم أتحقق من المسارات التي ربطت بها سابقًا لأرى ما إذا كان ذلك موجودًا بالفعل بطريقة ما).

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