معظم السياق موجود في العنوان.
نحن بصدد إجراء بعض التغييرات على تسجيل الدخول عبر SSO. والنتيجة هي أن المستخدم يمكنه تسجيل الدخول دون إعادة توجيه بعيدًا عن موقع Discourse.
يتم تحقيق ذلك عن طريق فتح إطار مضمن (iframe) إلى مزود SSO. ثم يتم إعادة التوجيه إلى عنوان URL الخاص بـ sso_login فقط بعد أن يعيد الإطار الرمز المميز.
لماذا لا تقوم بإجراء التعديلات باستخدام بنية الإضافات؟ عندها ستزول المشكلة.
ما زلت أراجع الكود المصدري، لذا ربما سيعمل الأمر. لكنني أزداد اقتناعًا بأن بنية الإضافة لا تمنحني التحكم الكافي لتحقيق ما أحتاجه.
أعتقد أنه يجب عليك النظر في البنية المعمارية وعدم الإصرار بشدة على استخدام إطار مضمن (iframe)، على سبيل المثال.
نوافذ تسجيل الدخول المنبثقة وعمليات الاستدعاء (callbacks) هي ممارسة قياسية، على سبيل المثال، وهي مباشرة جداً مع إضافة (plugin).
إدارة نسخة مشتقة (fork) من نظام Discourse ستكون نهجاً غير فعال تماماً وكابوساً مستمراً. وعلى النقيض من ذلك، إذا تم بناء الإضافات بشكل صحيح، فإنها يمكن أن تكون قوية جداً تجاه التغييرات وتتطلب صيانة أقل بكثير.
أولئك الذين حاولوا الحفاظ على نسخة متفرعة من Discourse يشعرون بالأسف الشديد. إما أن تحتاج إلى مطور بدوام كامل، أو دمج التغييرات، أو عدم الترقية مطلقًا. وفي النهاية، ستنتقل إلى إضافة (plugin).
أعتقد أنه يمكنك تحقيق ما تحتاجه من خلال إضافة، أو يمكنك جعلها تفعل ذلك من خلال طلب سحب (PR). يجب إما أن تشرح لماذا تعتقد أنه لا يمكنك حل مشكلتك عبر إضافة، أو أن تنشر في قناة Marketplace للحصول على المساعدة.
أقوم بإدارة Discourse كجزء من عملي (Redirecting…)، ولدي بعض العملاء الذين يحتاجون إلى تكوين مخصص ولكن لا يمكنهم تحمل تكاليف الاستضافة على مستوى المؤسسات. سأكون سعيدًا جدًا بالحصول على عملكم، لكنني لن أفكر أبدًا في دعم نسخة متفرعة.
سيكون من الأفضل استخدام إضافة، إذا أمكن.
سأواصل البحث، فمن المفيد معرفة مدى استقلالية بروتوكولنا عن OAuth على أي حال.
يمكنني أيضًا تأكيد أننا في Discourse.org لا نستضيف نسخة مشتقة من Discourse، حتى في خطتنا المؤسسية. يجب عليك إنشاء إضافات أو مكونات سمة لتغييراتك.