إعادة توجيه Onebox تمنع الارتباط بالمحتوى المقيد بتسجيل الدخول

Onebox follows redirects, which is usually a good thing, I guess.

This becomes a problem, however, when you share a link to a page requiring sign-in that simply redirects to a sign-in page when an anonymous user visits it.

For example, if I want to share my top secret project hosted at https://dgit.cs.uni-saarland.de/fefrei/my-top-secret-project/ in the internal category of our Discourse instance, this is what I get by default:

Note that all links in the Onebox go to https://dgit.cs.uni-saarland.de/users/sign_in, which is not helpful.

Of course, as a post author, I can prevent that by using any alternative markup that prevents the Onebox (which can’t show relevant content anyways); but if some other user does this and doesn’t notice, it’s pretty hard to retrieve the actual link.
As staff, I can edit the post to get the raw markup, but as a non-staff user, I think the only feasible workaround is to remember the magic /raw/ URL scheme.

Why does the Onebox link to the final location, not the original URL? Can we do something to improve this?

إعجابَين (2)

Why wouldn’t it link to the final location?

I typed https://dgit.cs.uni-saarland.de/fefrei/my-top-secret-project/, why should it link somewhere else?

When I’m redirected to the sign in page, this is fine, because I’m in a session – I can actually log in, and will be redirected back to the target URL.
When Discourse follows the redirect, forgets the original URL and just outputs the sign in URL, the reader has no (easy) way to get to the URL the author linked to.

Well, the workaround is to enter the link with angle brackets. It’s normal and expected to follow link redirects to the final destination.

I know that’s the current behavior, and already mentioned the workaround above:

I stumbled about this because another user fell for this trap, and I had to fish the actual link out of the raw view.

I’m not saying that this is terribad and needs to be fixed now or else; I’m just reporting that I find it sad that a user who simply pasted a link into his post got a Onebox that obfuscates the link in a way that makes it impossible for the average user to understand where to go. (There’s a reason I posted this in feature.)

إعجاب واحد (1)

لقد واجهت هذا السلوك اليوم وأؤيد تغييرًا في تجربة المستخدم.

الحالة التي لا ترغب فيها بالارتباط بالموقع النهائي هي عندما تتوقع أن يكون الأشخاص الذين تشاركهم الرابط مصادقًا عليهم أو قادرين على المصادقة على الموقع الذي ترتبط به.

هناك أيضًا الجانب الظاهري؛ فقد نشرت رابطًا لموضوع في discourse ضمن مجتمع آخر، وتم تغيير الرابط ليوجه إلى صفحة تسجيل الدخول. بدأ الناس يسألونني عما إذا كنت قد نشرت الرابط الخاطئ، لأنه من الغريب عمدًا ربط صفحة تسجيل الدخول. في النهاية، هذا يغير ما كان ينوي المستخدم نشره.

الحل البديل صحيح ولكنه ليس جيدًا؛ يجب أن تكون الافتراضات أكثر ذكاءً، خاصة إذا أردنا تجنب تجربة المستخدم السيئة لمن ينشر الرابط وللمستخدم الذي ينقر عليه.

3 إعجابات

لا أستطيع التفكير في أي طريقة أخرى للتعامل مع هذا سوى الترميز الصريح لمعالجة “تسجيل الدخول” عن طريق مطابقة السلاسل، وأنا لا أحب ذلك حقًا كحل، لأنه سيكون هشًا للغاية.

لماذا قد تحتاج إلى شيء من هذا القبيل؟

آسف إذا كان هذا هو مصدر اللبس، لكن ربما كانت طلبي الأول غير واضح. دعني أوضح:

افترض أن المستخدم يربط إلى https://example.org/a، لكن هذا الرابط يعيد التوجيه إلى https://example.org/login ما لم يكن المستخدم قد سجّل دخوله. السلوك الحالي:

  1. يطلب Discourse https://example.org/a ويتبع إعادة التوجيه.
  2. يطلب Discourse https://example.org/login ويسترجع العنوان والصورة، …
  3. يعرض Discourse صندوقًا واحدًا (Onebox) يعرض المعلومات المسترجعة من https://example.org/login، ويربط إلى https://example.org/login. لا يربط الصندوق الواحد المُنشأ إلى https://example.org/a في أي مكان.

فقط الجزء العريض هو ما أجد أنه إشكالي. نعم، اتبع الرابط واسترجع المعلومات منه بكل تأكيد، لكن يجب أن يربط الصندوق الواحد دائمًا إلى عنوان URL الذي أدخلته أنا.

لا يتعلق الأمر بأن يعرض الصندوق الواحد معلومات من صفحة تسجيل الدخول (فما الذي يجب أن يعرضه غير ذلك؟)، بل يتعلق بأن إنشاء الصندوق الواحد يحجب تمامًا هدف الرابط الأصلي.

إذا تم تنفيذ هذا، فسيبدو الصندوق الواحد في منشوري الأصلي مطابقًا، لكنه سيربط إلى https://dgit.cs.uni-saarland.de/fefrei/my-top-secret-project/.

هل هذا أكثر وضوحًا؟ :slight_smile:

3 إعجابات

ليس حقًا، حيث إن معظم “الروابط” على الإنترنت هي الآن تحويلات من نوع ما؟

لكن ما الخطأ في ذلك؟ سيعمل إعادة التوجيه أيضًا إذا نقر المستخدم عليه، تمامًا كما لو أن الرابط لم يكن مُضمَّنًا في صندوق واحد…

إعجاب واحد (1)

نعم.

من المنطقي أن يربط المربع الواحد إلى الشيء الذي ربطتَ إليه أنت، وليس إلى المكان الذي يتم إعادة التوجيه إليه. هذا يحل المشكلة ولا يكسر أي شيء يمكنني التفكير فيه.

إذا كان كل شيء يعيد التوجيه، فكلما كان من المنطقي أكثر الحفاظ على الرابط الأصلي.

3 إعجابات

أنا لا أتفق معك — فأنت تريد معرفة الوجهة النهائية المستهدفة، وليس مجرد حقيقة أنك نقرت على خدمة اختصار روابط عامة. لدي وجهة نظر معاكسة تماماً هنا.

عرض

مرحباً، ستضغط على link.is/ghwk4fe3

أقل فائدة بكثير من

مرحباً، ستضغط على example.com/funny-article

إعجاب واحد (1)

لكننا نتحدث هنا عن Oneboxes. لا تفعل ذلك أصلاً مع العناصر غير من نوع Oneboxes.
أيضاً، في الواقع، لا أمانع في إظهار الرابط النهائي. لكن عدم ربطه بالرابط الأصلي يكسر الروابط في سيناريوهات التي تتطلب تسجيل الدخول :frowning:

5 إعجابات

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

لا أمانع في أن يُظهر الصندوق الواحد محتوى الصفحة النهائية، لكن عدم الاحتفاظ بعنوان URL الأصلي يدمر أي فرصة لعمل إعادة التوجيه كما هو مقصود في هذا السيناريو. كما أنه يدمر أي علامات إسناد في الرابط الأصلي على أي حال.

3 إعجابات