يتم تجاهل blocked onebox domains في 2.9.0beta2 (c6265eec6b).
لدينا:
هذه النطاقات خلف جدران OAuth ويحاول onebox معاينة النطاقات والحصول على عنوان URL لتسجيل الدخول OAuth بدلاً من ذلك.
هذا الإعداد يؤثر على الخادم فقط - سيظل متصفحك يحاول إنشاء معاينة.
أتفهم كيف قد يكون هذا غير متوقع.
إذا قمت بإرسال المنشور، فهل يعرض المعاينة بعد أن يعرضها الخادم، أم يعرض عنوان URL فقط كما تتوقع؟
3 إعجابات
نعم، يبدو أن هذا لا يعمل بشكل صحيح… 
إعجاب واحد (1)
هل يمكنك محاولة إضافة “auth.pi-hole.net” في إعداد النطاقات المحظورة؟
لقد قمنا بتعيين هذا الإعداد بحيث يتبع عمليات إعادة التوجيه ولكنه يحظر النطاق المحدد فقط إذا كان هو الوجهة النهائية.
4 إعجابات
لقد حاولت للتو ولا يزال يتم عرضه كـ onebox. أعتقد أن هذا بسبب أن نقطة النهاية auth.pi-hole.net هي إعادة توجيه URI من نقطة النهاية OAuth على github.com. ونحن نفضل عدم حظر github.com من العرض كـ onebox.
سأتحقق وأرى ما إذا كان حظر github يفعل أي شيء… لا، حظر github.com لا يمنع العرض كـ onebox أيضًا. هل هناك ذاكرة تخزين مؤقت قد يستخدمها onebox وتحتاج إلى مسحها حتى يتم إجراء بحث جديد لـ tricorder؟
3 إعجابات
نعم، يمكنني فهم السبب.
توجد ذاكرة تخزين مؤقت ليوم واحد لعناوين الـ onebox التي تم جلبها، لذا فإن إعادة الخبز اليدوي للمنشور (post.rebake!) بعد يوم واحد من شأنه أن يمنع الـ oneboxing مع حظر github.com.
لدينا بعض الأعمال المتأخرة لتكون أكثر ذكاءً بشأن عمليات إعادة توجيه المصادقة، ولكن هذا يقتصر على المصادقة لمنتديات Discourse فقط. أفكر ربما في توسيع الإعداد للسماح أيضًا بالمسارات الفرعية سيساعدنا في هذه الحالة لـ github: \u003chttps://github.com/login/oauth/authorize\u003e … سأناقش هذا داخليًا.
من المحتمل أيضًا أن يكون من الجيد أن يكون النص التوضيحي محددًا بشأن ما يتم حظره فعليًا، ربما إضافة: “سيتبع الـ Onebox عمليات إعادة التوجيه ويحظر فقط إذا كانت الوجهة النهائية تطابق هذا الإعداد”.
4 إعجابات
فكرة جامحة… هل يجب أن ندعم:
cache-control: no-store
يشير توجيه الاستجابة
no-storeإلى أنه يجب ألا تخزن أي ذاكرة تخزين مؤقت من أي نوع (خاصة أو مشتركة) هذه الاستجابة.
GitHub يقول تحديدًا… من فضلك… لا تخزنني…
ربما يجب أن يحترم Onebox ذلك… ولا يخزنه.
يمكننا دائمًا جعل هذا إعدادًا تجريبيًا للبدء ورؤية التأثير الذي يحدثه.
سيتعين على المعاينة شرح سبب عدم قيامنا بـ oneboxing.
ملاحظة… نحن نستخدم no-store في العديد من الأماكن، ولكن أعتقد أننا نعيد التوجيه في تلك الحالات، ومع ذلك هناك هذه التعقيدات الطفيفة.
6 إعجابات
نحن نربط بالكثير من طلبات السحب والمشكلات من مستودعاتنا المختلفة، ووجود هذه العناصر المضمنة مع المعاينات يساعد المستخدمين الجدد على فهم الموضوع دون الحاجة إلى الدخول إلى GitHub.
إعجاب واحد (1)
نعم، أتفهم ذلك تمامًا، نحن نعمل على حل، أعتقد أن النظر إلى رأس “لا يوجد متجر” بعد يوم واحد هو أفضل طريقة للمضي قدمًا.
3 إعجابات
عذرًا على إزعاجك بهذا الأمر، لكنه يؤثر حقًا على موقع الدعم الخاص بنا. ينشر الأشخاص روابط إلى عنوان URL الخاص بـ tricorder وهي سجلات استكشاف الأخطاء وإصلاحها ليراجعها الموظفون المعتمدون. نتلقى عددًا من هذه المنشورات يوميًا ويجب علينا الدخول يدويًا وتغيير عنوان URL إلى شيء غير قابل للربط في الوقت الحالي.
هل هناك أي أفكار حول إطار زمني للحل أم أنه “قريبًا™” 
3 إعجابات
سنقوم بحل هذه المشكلة، أقول في غضون الأسابيع الأربعة القادمة تقريبًا.
4 إعجابات
كيف أفعل ذلك في Discourse Docker؟ 
أوصي بالانتظار حتى يتم تطبيق الإصلاح الخاص بنا، لدينا طلب سحب قيد التقدم:
إنه يعدل السلوك بحيث:
- نقوم بفحص القائمة المحظورة في كل قفزة في سلسلة إعادة التوجيه
- نقدم ميزة جديدة بحيث يمكن لأي موقع إلغاء الاشتراك في oneboxing عن طريق تعيين رأس مخصص
سيؤدي هذا إلى حل مشكلة @dschaper ومنحنا مزيدًا من المرونة في المستقبل.
للأسف، فإن اختيار no store سيؤدي إلى شبكة واسعة جدًا وسيلتقط الكثير من النتائج الإيجابية الخاطئة.
6 إعجابات
تم دمج طلب السحب وهو موجود في الفرع tests-passed. هل يمكنك ترقية @dschaper ومعرفة ما إذا كان ذلك يحل المشكلة؟ يجب ألا تظهر عناوين URL ذات النطاق tricorder.pi-hole.net مرة أخرى في موقعك.
7 إعجابات
يبدو كل شيء جيدًا هنا!
شكرًا للجميع على الإصلاح.
4 إعجابات