Xterm.js: دعم هروب الارتباط التشعبي ansi

فكرة جيدة ، مرحبا العلاقات العامة!

يمكن أن يصبح معيارًا ويجعل التحليل أسهل.
قضية ذات صلة: https://github.com/xtermjs/xterm.js/issues/583

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

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

على سبيل المثال ، يمكنك إنشاء رابط يحمل العنوان "login.facebook.com" ولكن في الواقع ربطه بـ login.faceboook.com ، مع وجود صفحة تبدو متطابقة تمامًا ، مع حفظ كلمة مرور المستخدمين عند تسجيل الدخول.

يعرض iTerm2 عنوان URL مثل هذا:

هذا أيضًا مشابه لكيفية عرض Chrome لعنوان URL عند تمرير الماوس فوق الروابط.

إذا / عند تنفيذ ذلك ، يرجى إرسال مشكلة أو PR إلى supports-hyperlinks ، والذي يهدف إلى اكتشاف الدعم لهذه الإمكانية.

jamestalmage ربما يجب ترك هذا الأمر لتضمينات xterm.js ، في الوقت الحالي ، البيئة مملوكة لمحاكيات المحطة الطرفية التي تستخدم xterm.js. على سبيل المثال ، يتم تعيين Hyper و VS Code بشكل فردي على TERM_PROGRAM .

Tyriar - في هذه الحالة ، ربما قم فقط بتضمين إشارة إلى supports-hyperlinks في الالتزام الذي يصل إلى هذا ، وفي ملاحظات الإصدار عندما يتسع النطاق. لست متأكدًا مما إذا كان هناك ما supports-hyperlinks للغات أخرى ، ولكن إذا كان الأمر كذلك ، فمن الجدير بالذكر أيضًا.

لدي تطبيق لإثبات صحة المفهوم:

links.txt

هناك مشكلة أساسية تتمثل في عدم تخزين هذه الروابط في المخزن المؤقت بأي طريقة حقيقية ، لذلك تختفي إذا تم تغيير حجم النافذة. بدلاً من ذلك ، يتم تخزين معلومات الارتباط في MouseZoneManager الذي تم مسحه بواسطة _mouseZoneManager.clearAll .

أعتقد أن الإصلاح الحقيقي يجب أن ينتظر حتى تتم إعادة تنفيذ Buffer. نحن بحاجة إلى آلية لإضافة تعليق توضيحي للخلايا و / أو نطاقات الخلايا ، وتكون ثابتة عند تغيير الحجم.

(أو ربما أفتقد شيئًا ما ، لكوني جديدًا على قاعدة الرموز هذه.)

أعتقد أن الإصلاح الحقيقي يجب أن ينتظر حتى تتم إعادة تنفيذ Buffer. نحن بحاجة إلى آلية لإضافة تعليق توضيحي للخلايا و / أو نطاقات الخلايا ، وتكون ثابتة عند تغيير الحجم.

PerBothner نعم ربما أنت على حق. هناك شيء آخر نحتاج إلى التفكير فيه قبل أن يكون هذا قابلاً للشحن وهو كيفية الكشف عن عنوان URL الأساسي من xterm.js بحيث يمكن للتضمينات عرضه في واجهة المستخدم. ربما نرغب أيضًا في إيقاف تشغيله افتراضيًا لأسباب أمنية (نظرًا لأن عنوان URL لن يظهر افتراضيًا).

لقد قمت بتحديث التصحيح الخاص بي ودفعته إلى فرع: https://github.com/PerBothner/xterm.js/tree/hyperlinks

غير جاهز لطلب السحب ، بالرغم من ذلك - لم يتم معالجة العديد من المشكلات المذكورة سابقًا.

اقتراح لواجهة برمجة التطبيقات لاستخدام هذا:

export class Terminal {
    /**
     * Adds a handler for the ANSI hyperlink escape `\x1b]8;;url\alabel\x1b]8;;`, you should use
     * this API to display the full URL to the user. Note that ANSI hyperlinks will only work if
     * there is a handler for security reasons.
     * <strong i="6">@param</strong> onHover The callback that fires when the mouse enters a link's zone.
     * <strong i="7">@param</strong> onLeave The callback that fires when the mouse leaves a link's zone.
     * <strong i="8">@return</strong> An IDisposable which can be used to disable the handler.
     */
    addAnsiHyperlinkHandler(onHover: (event: MouseEvent, url: string) => void, onLeave: () => void): IDisposable;
}

mofux ردود الفعلjerch على شكل API؟ لا يمكنني العثور على هذا الموضوع يتحدث عن شكل هذه ، ولكن ربما يجب أن يكون هذا set بدلاً من add لأنه من المنطقي أن يكون لديك 1.

قد يكون من الأفضل أيضًا استخدام شيء مثل ILinkHoverEvent :

interface ILinkHoverEvent {
  // Maybe the cell the mouse is under is also needed?
  x1: number;
  y1: number;
  x2: number;
  y2: number;
  url: string;
}

export class Terminal {
    addAnsiHyperlinkHandler(onHover: (event: ILinkHoverEvent) => void, onLeave: () => void): IDisposable;
}

بديل آخر:

interface ILinkHoverEvent {
  linkStart: Cell;
  linkEnd: Cell;
  mousePosition: Cell;
  url: string
}

Tyriar IMO ليس من المنطقي إنشاء معالج منفصل لهذا الغرض. سيكون المستهلك المحتمل لواجهة برمجة التطبيقات هذه هو العارض الذي يعرض عنوان url في تلميح أداة إذا قمنا بتحريك النص المرتبط ، أليس كذلك؟ ربما يكون من المنطقي تمديد رابطنا باستخدام الخطافات المذكورة أعلاه مقابل onLinkHover و onLinkLeave ، وهل يتم التعامل مع ارتباطات ansi كما نفعل مع روابط الويب الآن؟

سيكون المستهلك المحتمل لواجهة برمجة التطبيقات هذه هو العارض الذي يعرض عنوان url في تلميح الأدوات

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

أعتقد أن الدمج في واجهة برمجة التطبيقات للرابط الحالي ولديك إعداد ITerminalOptions.enableAnsiHyperlinks للاشتراك وتفاصيل لماذا؟

كيف ستكون قصة أدوات التطعيم لدعم هذه الميزة؟ من المحتمل أن يكون فتح الرابط (غير المرئي) عند النقر على النص المرتبط أمرًا خطيرًا - خاصةً إذا لم نعرض عنوان URL المرتبط في أي مكان 🤔

بينما يُعد إظهار الهدف مقدمًا أمرًا رائعًا حقًا ، لا أعتقد أن هناك مشكلة في فتح عناوين URL "غير معروفة". تمت مناقشة الجوانب الأمنية في التعليقات تحت المواصفات. تفتح المتصفحات عناوين URL "غير معروفة" طوال الوقت ، على سبيل المثال ، عندما يكون هناك رمز JS يغير الهدف قبل فتحه ، غالبًا لإظهار عنوان URL "لطيف" للمستخدم ، ولكن في الواقع يفتحه من خلال معيد التوجيه.

بالحديث عن ... شيء لم يحدث لي حتى الآن ...

إذا كان xterm.js يعمل داخل متصفح حقيقي ، ويفتح الرابط ، فلنقل علامة تبويب جديدة لهذا المتصفح: أعتقد أن تسريب عنوان URL الخاص بـ xterm.js عبر حقل Referer أمر يدعو للقلق. لست متأكدًا من الدعم الحالي لـ rel = "noreferrer" ، ولكن يبدو أنه شيء يجب استخدامه.

راجع هذه المناقشة ذات الصلة حول نص التمرير . تتعلق هذه المشكلة بالتعليق التوضيحي لأقسام الإخراج باستخدام "قمم الأدوات" والنوافذ المنبثقة الأخرى التي يتم تمرير الماوس فوقها ، والتي تختلف عن عرض عنوان URL عند التمرير فوق ارتباط. ومع ذلك ، قد يرغب كلاهما في استخدام نفس الآلية لعرض نص التمرير الفعلي. من المحتمل أن يستخدم كلاهما MouseZoneManager .

هل لدينا أي خبراء XSS يتجولون؟ ربما نحتاج إلى مراجعة ، لول.

لمعرفتي المحدودة حول أمان المتصفح ، فإن متجه الهجوم الرئيسي باستخدام xterm.js هو عبور البيانات للحدود الطرفية / المتصفح:

• XSS من المتصفح (JS) إلى المحطة (البيانات)
  هذا ممكن بالفعل ومسؤولية التكامل (لا يستطيع xterm.js التحكم في ذلك بأي وسيلة). القاعدة العامة - لا تستورد أبدًا البرامج النصية من أي مصدر غير موثوق به على الصفحة الطرفية أو pty websocket وبالتالي يتم فقد النظام الذي يستضيف pty. لا تسمح بإدراج محتوى المستخدم غير المرشح في الصفحة وما إلى ذلك - بشكل أساسي ، يتم فقد جميع عناصر XSS النموذجية ، أو يتم فقد pty.
• XSS من المحطة (البيانات) إلى المتصفح (JS)
  هذه جودة جديدة قد ندخلها باستخدام عناوين URL ، إذا لم نتأكد من أن البيانات الطرفية لن تصل أبدًا إلى سياق JS لصفحة التضمين (وبالتالي الكائن الطرفي نفسه). إذا كان ذلك ممكنًا (لنفترض أنه لثانية واحدة) يمكن للمهاجم الوصول إلى صفحة المتصفح ، وبالتالي القيام بهجوم طرفي (بيانات) - متصفح (JS) - طرفية (بيانات). لنفترض كذلك أن xterm.js يعمل كثيرًا في بوابات الخدمة السحابية المنظمة ويستخدم المسؤول جلسات طرفية لأجهزة مختلفة. انتش. بمجرد أن يتمكن المهاجم من الوصول إلى صفحة متصفح التضمين ، فإن جميع الخدمات السحابية التي يستطيع المسؤول الوصول إليها في خطر.

السؤال هو - هل هناك احتمالات لعبور الحدود الطرفية (البيانات) - المتصفح (JS) مع عناوين URL؟ مرة أخرى ، لا تساعد معرفتي المحدودة بأمان المتصفح كثيرًا هنا. السيناريو الوحيد الذي يمكنني التفكير فيه هو الإشارات المرجعية التي تدخل نفسها في JS للصفحة. ليس لدي أدنى فكرة عما إذا كان بإمكاننا تجنب ذلك عن طريق فتح العناصر دائمًا في نافذة / علامة تبويب جديدة فقط (تخمين أن الجلسة ستستمر في التسريب ، إن لم يكن httpOnly؟ ماذا عن اتصال websocket؟) مما يجعلني أعتقد أنه يتعين علينا تحليل عنوان URL وتجريد أي "محتوى يشبه JS" ، يا عزيزي ...

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

تزيل الإشارات المرجعية [...] أي "محتوى بتنسيق JS"

أعتقد أنه من الجيد وضع عناوين URL التي تبدأ بـ "http: //" و "https: //" وربما "ftp: //" في القائمة البيضاء ورفض أي شيء آخر. أو على الأقل القائمة السوداء لعدم وجود مخطط بالإضافة إلى "جافا سكريبت:".

في فرع الارتباطات التشعبية الخاص بي ، أضفت تصحيحًا https://github.com/PerBothner/xterm.js/commit/b2647b90d301c52229d01720800865a0d39f436f لوظيفة رد اتصال قابلة للتعيين بنقرة واحدة. هذا يسمح بتغيير كيفية التعامل مع الارتباط. على سبيل المثال ، عندما يتم تكوين DomTerm لاستخدام فرع xterm.js الخاص بي بعد ls --hyperlink=auto سيؤدي الضغط على معظم أسماء الملفات إلى فتح الملف في emacs ، لكن ملفات html ستفتح الملف في متصفحك الافتراضي ، اعتمادًا على إعداداتك .

(كن حذرًا من وجود بعض الهشاشة في النموذج الأولي. لا أعرف ما إذا كان ذلك خاصًا بنموذج DomTerm الأولي.)

تفتح المتصفحات عناوين URL "غير معروفة" طوال الوقت ، على سبيل المثال ، عندما يكون هناك رمز JS يغير الهدف قبل فتحه ، غالبًا لإظهار عنوان URL "لطيف" للمستخدم ، ولكن في الواقع يفتحه من خلال معيد التوجيه.

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

في فرع الارتباطات التشعبية الخاص بي ، أضفت تصحيحًا PerBothner @ b2647b9 لوظيفة رد

PerBothner يوجد بالفعل معالج هنا في ملحق webLinks: https://github.com/xtermjs/xterm.js/blob/509ce5fa3a698ee7847419117e9dd6b979b105bf/src/addons/webLinks/webLinks.ts#Lugly إعداد 2 معالجات ارتباط ويب مختلفة.

(آسف على الرد المتأخر - لقد تم تعقبي جانبي.)

كتب Tyriar "يوجد معالج هنا بالفعل في ملحق WebLinks". تكمن المشكلة في أن webLinksInit ينشئ ILinkMatcher ، ويربط المعالج المحدد بـ ILinkMatcher محدد ، والذي يحتوي على مجموعة من regexes لمطابقتها. ولكن كيف نحدد معالج الارتباط للارتباطات التشعبية التي تم إنشاؤها بواسطة تسلسل هروب وبالتالي فهي ليست نتيجة تطابق regex؟ يحتاج هذا المعالج إلى "عالمي" ، بمعنى أنه لا يرتبط بأي ILinkMatcher أو regex. تعيين هذا المعالج العام / الافتراضي باستخدام webLinksInit أو Terminal.registerLinkMatcher لا يعمل.

يبدو لي أننا بحاجة إلى حقل linkHandler في Terminal - فوجود حقل handler في ILinkMatcher ليس كافيًا. وإذا كان لدينا مثل حقل linkHandler في Terminal فمن المنطقي أن يكون هذا المعالج هو الافتراضي المستخدم بواسطة registerLinkMatcher. هذا ما تفعله رقعة بلدي.

إذا أراد شخص ما المساعدة في ذلك ، فإليك ما يجب أن يحدث:

• اكتشف كيفية التعامل مع الآثار الأمنية لوجود روابط لا تظهر كعناوين URL ، ومن المحتمل أن يكون هذا هو تمكين الميزة وكشف خطاف حتى يتمكن المستهلكون من إظهار نافذة منبثقة
• اكتشف واجهة برمجة تطبيقات لطيفة لفتح رابط ، فلدينا بالفعل شيء مشابه جدًا لواجهة برمجة تطبيقات مطابقة الروابط ، هل يمكن تعميم ذلك؟
• أضف المنطق إلى المحلل اللغوي وقم بتخزين الروابط في مكان ما ، ربما مثل IMarker s؟

يمكن أن يكون فرع الارتباطات التشعبية الخاص بي https://github.com/PerBothner/xterm.js/tree/hyperlinks نقطة انطلاق. (على الرغم من أنها قديمة بعض الشيء ، فقد لا تعمل بعد الآن.)

ما هي حالة الفرع أعلاه؟ هل هناك من يعمل على هذا؟
Tyriar سرد بلطف الخطوات المطلوبة. هل تم تنفيذ أي من هذه الخطوات؟

@ Jma353 لا أعتقد أن أي شخص يعمل بنشاط على هذا ، لذلك لا تتردد في تنفيذ البتات المطلوبة.

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

jerch نعم سيحتاج بعض التغييرات المحلل اللغوي. يعد تغيير حجم الروابط المغلفة حالة نحتاجها للتأكد من أنها تعمل أيضًا.

يحتوي VS Code الآن على دعم لإظهار التحركات التفصيلية للروابط ، لذا فإن ربط هذا بهذا سيؤدي إلى حل المشكلة:

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

Tyriar أيضًا مع # 2751 ، يمكن استخدام تخزين

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

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