تخطي "السماح بالوصول إلى التطبيق"

مطور
1

نحن نستخدم Discourse كأداة للتعاون، ولدينا تطبيق آخر للبحث في المستندات. نود دمج التعليقات على المستندات في Discourse. كلا التطبيقين يستخدمان مزوّد SSO/Oauth خارجيًا ضمن بنيتنا التحتية.

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

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

جربنا استدعاء UserApiKeysController.create أولاً (بدلاً من UserApiKeysController.new) لكننا واجهنا خطأ CSRF. لذا حاولنا تجاوز فحص الرمز كما يلي:

class UserApiKeysController < ApplicationController
  skip_before_action :verify_authenticity_token

لكن هذا لم ينجح أيضًا.

هل ترون طريقة أخرى للقيام بذلك؟

شكرًا مقدّمًا

2

مرحبًا بك يا برونو، يسعدنا انضمامك إلينا هنا :slight_smile: ربما لدى @david أو @blake بعض الأفكار حول هذا.

3

يمكنني القول بثقة أن هذا ليس المسار الصحيح. هل تستخدم بالفعل إضافة (plugin)، أم أنك تتفاعل فقط عبر HTTP؟

إذا كنت تستخدم إضافة، فلا ينبغي لك في الغالب التفاعل مع نسخ من app/controllers/.

إذا كنت تتفاعل عبر HTTP، و تستخدم اتصالاً بين الخوادم، فسيكون من الأفضل لك استخدام مفتاح API تم إنشاؤه بواسطة المسؤول.

يُقصد بواجهة برمجة تطبيقات المستخدم (User API) للاتصال من العميل إلى الخادم، حيث لا توجد طريقة لتوفير تكامل الكود على جانب العميل.

4

نعم، نحن نخطط لتطوير إضافة لـ Discourse، وستتفاعل تطبيقنا الجافا سكريبت فقط عبر طلبات HTTP.
نود تجنب الحاجة إلى تطوير اتصال بين الخوادم (على سبيل المثال باستخدام مفتاح واجهة برمجة التطبيقات المسؤول) لتقليل الارتباط بين المكونات.

أفهم أنه من المثالي ألا نتدخل في وحدات تحكم Discourse، وفي الوقت نفسه، هناك العديد من الطرق التي تبدو مصممة للتعديل (نمط طريقة القالب ونقاط التوسع الأخرى)، ومن ما رأيناه حتى الآن، فإن العديد من الإضافات تفعل ذلك.

إذن، ما هو الطريق الصحيح الذي يجب اتباعه؟

5

إذا كنت تقوم بكتابة إضافة، فيجب عليك تطوير مسارات جديدة في وحدة تحكم مثبتة ضمن الإضافة تؤدي مباشرة المهام المطلوبة. يمكن لهذه المسارات جميعها مشاركة before_action واحد يُعدّ رؤوس الاستجابة Access-Control-Allow-{Origin, Headers, Credentials} (عكس رأس طلب Origin إذا كان ضمن قائمة النطاقات التي يجب أن تعمل عليها تطبيقك).

بهذه الطريقة، يمكن لرمز JavaScript الخاص بك ببساطة استدعاء fetch(..., { credentials: "include", ...}) دون الحاجة إلى أي مفتاح API.

6

شكرًا لك @riking، هذا يعمل بشكل جيد عندما يكون لدينا جلسة مفتوحة على discourse في المتصفح.

نحن قادرون على بدء جلسة جديدة يدويًا عن طريق استدعاء http://discourse_site/login مباشرة، حيث أن SiteSetting.enable_local_logins = false ونستخدم آلية مصادقة واحدة فقط وهي OAuth. يقوم المتصفح بمتابعة التحويلات إلى مزود OAuth الخاص بنا ثم يعيد التوجيه إلى discourse. وهذا ما كان يحدث في الخلفية عند استدعاء /user-api-key/new.

كيف يمكننا بدء جلسة discourse جديدة برمجياً من التطبيق إذا لم تكن هناك أي جلسة حالية؟