هل هناك طريقة يمكن للواجهة الخلفية من خلالها تحويل جميع الروابط الجزئية في المنشورات (example.com) إلى روابط https (https://www.example.com)؟
يبدو أنها تُنشأ كروابط http://، مما يؤدي إلى فوضى كاملة عندما تفشل طلبات HTTP الخارجية http://example.com للعديد من المستخدمين الذين ينقرون عليها من المنشور.
(أو، التحقق من عنوان الوجهة المُنشأ وتعديله إلى البروتوكول الصحيح للوصول إليه؟)
شكرًا، هذا هو سؤالي الأول، عذرًا إذا كان مكررًا ولكني لم أجد شيئًا موجزًا حول هذا الموضوع.
ميتش
يبدو أن الوقت قد حان لجعل تلك الروابط https افتراضيًا. قد يكون هذا طلب ميزة.
لا، هذا غير صحيح. هناك العديد من المواقع التي تستخدم http، لأنها ببساطة لا تحتاج إلى SSL.
هل ستكون هذه مهمة أخرى عادية للبحث والاستبدال؟ أم أنني أسأت فهم كل شيء مرة أخرى؟
بالإضافة إلى ذلك، أنا قلق بشأن موقف حرج حيث يستخدم Discourse خادم VPS خاص به، وأمامه خادم VPS آخر حيث يوجد وكيل عكسي. سيتحدث هذان الخادمان إلى بعضهما البعض بدون SSL في كثير من الأحيان.
لكن هذا وضع مختلف تمامًا، أليس كذلك؟ لكنني بدأت أشعر بالتوتر في كل مرة يكون هناك شيء افتراضي يمكن أن يتغير بالنسبة لي بالاختصارات المألوفة…
أعتقد أنك مخطئ في أن هذه المواقع لا تحتاج إلى https. لا يوجد عذر لعدم تأمين موقعك الآن.
ولكن يبدو أنني مخطئ في أن هذا يجب أن يكون طلب ميزة. يجب أن يتعامل المتصفح بدلاً من المناقشة مع فرض https.
أنا متأكد من أن المتصفحات الحديثة تعطي الأولوية لـ HTTPS على HTTP افتراضيًا.
أيضًا، تقوم العديد من مواقع الويب من جانب الخادم بإعادة التوجيه إلى HTTPS أو استخدام رأس HSTS.
لا أعتقد أنني مخطئ عندما نتحدث عن الواقع.
الحاجة إلى تأمين الاتصالات بين الخوادم باستخدام SSL عندما لا تتضمن البيانات أي شيء يحتاج إلى تأمين تستحق موضوعًا آخر. لكن هذا خارج الموضوع تمامًا هنا.
لكن إخبار المستخدمين بأنه آسف، لا يمكنك الارتباط لأن طرفًا ثالثًا لا يستخدم المنفذ 443 هي فكرة سيئة. ليس من وظيفة المسؤول أو حتى وظيفة discourse أن يقرر ما يجب على شخص ما فعله.
نعم، إذا كان موجودًا. وبعض أجهزة التوجيه/المودم المنزلية مهيأة لاستخدام https فقط وهذا مزعج حقًا. لأن ليس كل موقع يتبع رغبة Google في استخدام SSL في كل مكان، وجزئيًا لأن العديد من المنصات تقدم روابط قديمة باستخدام http وهذه الأجهزة الغبية لا يمكنها إعادة كتابة عنوان URL.
لذلك قبل أي مناقشة للميزات، يجب أن يكون هناك موضوع ميتا آخر أولاً: هل تقع على عاتق منصة المنتدى مسؤولية فرض استخدام SSL للروابط الصادرة.
بعد ذلك، يكون الحل التقني سهلًا بشكل معقول، على ما أعتقد - ولكن مرة أخرى، أنا لست مطورًا.
لكن بالعودة إلى الموضوع.
إذًا، البحث والاستبدال ليس حلاً حادًا؟ لكنني لا أتابع الآن… مرة أخرى… هل المشكلة الحقيقية هي أن Discourse يشكل روابط تلقائيًا إذا تم إعطاء عنوان URL عادي؟ إذا كان الأمر كذلك، فأنا أعود قليلاً ونعم، يجب أن يكون https تلقائيًا - ولكن يجب أن يكون قابلاً للتحرير.
التحقق مما إذا كان بروتوكول http (و https بوظيفة مماثلة) ممكنًا، باستخدام رأس الصفحة المستهدفة فقط، تم نسخ الكود من:
def check_http_url(url):
HTTP_URL = f'http://{url}'
try:
HTTP_URL = urlparse(HTTP_URL)
connection = HTTPConnection(HTTP_URL.netloc)
connection.request('HEAD', HTTP_URL.path)
if connection.getresponse():
return True
else:
return False
except:
return False
إذن مع ذلك (مترجم إلى Ruby إذا كنت أتذكر)، يمكن لـ Discourse back-end معرفة ما إذا كان الهدف من رابط جزئي معطى في منشور هو https أو http، ثم (مع تفضيل https) فتح الرابط الهدف الصحيح للمستخدم؟