That was!! You save my day… Thanks a lot!
Could be wrong, but doesn’t this open up a x-site security vulnerability? See:
إعجابَين (2)
I don’t know much in these matters, but here is my reasoning:
- “same site cookie” is enabled by default, so it is probably much better this way.
- “same site cookie” can be disabled, so it’s probably not a security hole by itself, rather a weakness that could be exploited in conjunction with others. Disable it at your own risks.
Anyone understands why disabling same site cookie enforcement prevents users from log in within an iframe?
هل يمكننا الحصول على دعم رسمي لـ Discourse داخل إطار مضمن (iframe)؟
تحرير: أوه، آسف، لم أدرك أنني أكتب بعد مرور عامين.
من غير المرجح جدًا أن يتم دعم ذلك أبدًا.
إعجابَين (2)
جيف،
أولاً: ديسكورش رائع تمامًا، وشكرًا لك على بنائه!
ثانيًا: هل هناك وثائق توضح المشاكل المحددة المتوقعة عند تضمين ديسكورش داخل إطار مضمن (iframe)، أو ما هي القيود التي قد تؤثر عليه من حيث المبدأ؟
شكرًا لك!
مرحبًا آدم، لقد مرّ وقت طويل، دعني أحاول الإجابة هنا.
استخدام وسم <iframe> عرضة للأخطاء بشكل كبير وسيجعل Discourse صعب الاستخدام ومليئًا بالأخطاء التي يصعب تتبعها. كما أنه يميل إلى “عزل” نفسه داخل Discourse، مما يتسبب في مشاكل مثل التمرير عبر المواضيع الطويلة. باختصار، تقوم الإطارات المنبثقة (iframes) بعزل العديد من ميزات Discourse.
الطريقة الجيدة التي يمكنك اتباعها إذا كنت تفكر في استخدام iframe هي إضافة رأس (header) إلى منتداك يتطابق مع باقي موقعك/تطبيقك/بوابتك، بما في ذلك روابط التنقل. عندما ينقر المستخدم للدخول إلى المنتدى، سيرى تنقلًا مشابهًا لكنه سيكون على عنوان URL مختلف مستضاف في مكان آخر. وعندما ينقر على رابط غير خاص بالمنتدى في الرأس، سيعود إلى الموقع/التطبيق/البوابة.
أتمنى أن يكون هذا مفيدًا.
إعجابَين (2)
شكرًا لك على ردك!
هل يمكنك مشاركة المشكلات المحددة التي يُتوقع حدوثها؟ أو الأسباب المحددة التي قد يتسبب فيها سياق الـ iframe في مشاكل خطيرة؟
ماذا يعني “window” في هذه الحالة؟
هذا ما سنفعله لمنطقة النقاش الرئيسية لدينا، لكنه يمثل مشكلة في حالة الاستخدام المحددة هذه. نحن ندير دورات تعليمية عبر الإنترنت. تحدث كل دورة في منطقة خاصة ذات طابع خاص بموقعنا. تتضمن محتوى الدورة مواد الصفوف، والفيديوهات، والجدول الزمني، ومنطقة للنقاش. بمجرد إكمال الطلاب للدورة، يمكنهم مواصلة النقاشات التي بدأوها مع المشاركين الآخرين في مجموعة الدورة. كما يتم إضافتهم إلى مجموعة نقاش عامة لخريجي الدورة، وسيتم أيضًا دعوتهم إلى منتدى النقاش العام الأكبر لدينا.
لحالة الاستخدام لدينا، هناك مشكلتان في النهج المقترح هنا:
-
الثيم (الرأس، الأنماط، الشريط الجانبي، إلخ) لمنطقة الدورة على موقعنا لا يطابق الثيم الذي نرغب في استخدامه لـ Discourse بشكل عام. ولتوفير ذلك، سنحتاج إلى القدرة على استخدام أنماط ومحتوى ثيم مختلف لكل فئة، وهو ما لا يبدو ممكنًا.
-
يتضمن نقاش الدورة في تطبيقنا الحالي (غير القائم على Discourse) أنماطًا ورأسًا وقائمة شريط جانبي. إنه مساحة منخفضة التشتت حيث يمكن للطلاب التركيز على محتوى الدورة والتبديل بسلاسة بين النقاش ومواد الصفوف والفيديوهات، إلخ. قدر علمي، سيكون من الصعب تعديل Discourse لمحاكاة هذه البيئة الغامرة. وإذا لم يكن الأمر كذلك، فسأكون سعيدًا لمعرفة عكس ذلك!
شكرًا لك على مساعدتك،
آدم
هذا ممكن. سيكون لعنصر body فئة تشير إلى الفئة الحالية، مما يسمح لك بتحديد نطاق السمة بسهولة باستخدام محددات متداخلة في SCSS.
بشكل عام، أوصيك بإضافة بضع أدوات (widgets) من Discourse إلى منطقة الدورة التدريبية، مثل ميزة قائمة المواضيع المضمنة عبر iframe المدعومة لدينا والمُوثّقة في تضمين قائمة بمواضيع Discourse في موقع آخر. بهذه الطريقة، يمكن للطلاب رؤية قائمة بأحدث المناقشات المتعلقة بصفحة الدورة الحالية الخاصة بهم، وسيكونون على بعد نقرة واحدة من الانضمام إليها في علامة تبويب متصفح أخرى!
3 إعجابات
مرحبًا يا فالكو،
شكرًا لك على ردك، وأعتذر عن التأخير في الرد.
لسوء الحظ، فإن تنفيذ الدورات لدينا أكثر تعقيدًا مما يمكن أن يتحمله نطاق CSS مخصص دون حيل معقدة. على سبيل المثال، يتضمن قائمة الرأس قائمة منسدلة للدورات التي سجل فيها المستخدم الحالي. يتم إنشاؤها ديناميكيًا من قاعدة بيانات ووردبريس بناءً على المستخدم المسجل، لذا سيكون من الصعب إعادة إنتاجها في ديسكورا.
تتضمن القائمة الجانبية في منطقة الدورات روابط لمختلف أنواع محتوى الدورات، وهي محددة لدورة معينة. إذا فهمت بشكل صحيح، لكي يعمل ما تصفه، فسيكون من الضروري تضمين كل هذا المحتوى، لجميع الدورات، بشكل ثابت في السمة، ثم إظهاره أو إخفاؤه بواسطة CSS اعتمادًا على فئة الجسم. هل هذا صحيح؟
منهجية واحدة قد تعمل هي استخدام بعض جافا سكريبت على جانب العميل في ديسكورا لجلب المحتوى من واجهة برمجة التطبيقات (API) الخاصة بنا وعرضه. هل من الممكن إضافة نصوص مخصصة تقوم بطلبات XmlHttpRequest إلى خوادم أخرى؟ هل ترى أي سبب يجعل هذا غير ممكن؟
ما زلنا نأمل في الحصول على إجابة لهذا السؤال.
شكرًا لك!
نعم، هذا ممكن. فقط انتبه لعدم جعل هذه الطلبات تعيق عرض الصفحة.
إعجابَين (2)