Xterm.js: हाइपरलिंक ansi बच का समर्थन करें

अच्छा विचार है, पीआर आपका स्वागत है!

यह एक मानक बन सकता है और पार्सिंग को आसान बना सकता है।
संबंधित मुद्दा: https://github.com/xtermjs/xterm.js/issues/583

सबसे बड़ा लाभ यह है कि हम एक लंबे URL के साथ टर्मिनल को स्पैम किए बिना पाठ को लिंक कर सकते हैं। उदाहरण के लिए, कोई त्रुटि संदेशों में प्रलेखन को सुपर वर्बोज़ किए बिना लिंक कर सकता है।

इसे ध्यान से लागू किया जाना चाहिए, आपको यह देखने के लिए लिंक को हॉवर करने में सक्षम होना चाहिए कि यह कहां जाता है, अन्यथा आप उपयोगकर्ताओं को अनजाने में दुर्भावनापूर्ण साइटों से जोड़ सकते हैं। ईमेल फ़िशिंग में यह पहले से ही एक बड़ी समस्या है।

उदाहरण के लिए आप एक लिंक बना सकते हैं, जिसका शीर्षक "login.facebook.com" था, लेकिन वास्तव में इसे login.faceboook.com से लिंक करें, जिसमें एक पेज बिल्कुल एक जैसा दिखता है, लेकिन लॉगिन पर उपयोगकर्ताओं के पासवर्ड को सहेजना।

iTerm2 इस तरह URL दिखाता है:

यह भी इसी तरह है कि जब आप लिंक मँगाते हैं तो क्रोम URL कैसे दिखाता है।

यदि / जब इसे लागू किया जाता है, तो कृपया एक समस्या या PR को supports-hyperlinks , जिसका उद्देश्य इस क्षमता के लिए समर्थन का पता लगाना है।

@jamestalmage को शायद TERM_PROGRAM ।

@ तीयरार - उस स्थिति में, शायद supports-hyperlinks एक ऐसा कमिटमेंट शामिल है जो इस भूमि को, और विमोचन नोटों में जब यह चौड़ा हो जाता है। मुझे यकीन नहीं है कि अगर अन्य भाषाओं के लिए supports-hyperlinks समतुल्य हैं, लेकिन यदि हां, तो शायद उनका भी उल्लेख करने लायक है।

मेरे पास प्रूफ-ऑफ-कॉन्सेप्ट कार्यान्वयन है:

links.txt

इसमें एक बुनियादी समस्या यह है कि ये लिंक किसी भी वास्तविक तरीके से बफर में संग्रहीत नहीं हैं, इसलिए खिड़की के फिर से आकार में आने पर वे चले जाते हैं। इसके बजाय, लिंक जानकारी में संग्रहित है MouseZoneManager जिसके द्वारा मंजूरी दे दी है _mouseZoneManager.clearAll ।

मेरा मानना ​​है कि जब तक बफ़र को फिर से लागू नहीं किया जाता है तब तक एक वास्तविक सुधार का इंतजार करना होगा। हमें कोशिकाओं और / या सेल श्रेणियों को एनोटेट करने के लिए एक तंत्र की आवश्यकता है, जो आकार बदलने पर स्थिर है।

(या हो सकता है कि मुझे कुछ याद आ रहा है, इस कोड-बेस में नया है।)

मेरा मानना ​​है कि जब तक बफ़र को फिर से लागू नहीं किया जाता है तब तक एक वास्तविक सुधार का इंतजार करना होगा। हमें कोशिकाओं और / या सेल श्रेणियों को एनोटेट करने के लिए एक तंत्र की आवश्यकता है, जो आकार बदलने पर स्थिर है।

@PerBothner हाँ तुम शायद सही हो। इससे पहले कि यह shippable है, इसके बारे में हमें एक और बात सोचने की ज़रूरत है कि अंतर्निहित URL xterm.js से कैसे उजागर होता है, इसलिए एम्बेडर्स इसे UI में प्रदर्शित कर सकते हैं। हम शायद सुरक्षा कारणों से डिफ़ॉल्ट रूप से इसे बंद करना चाहेंगे (चूंकि 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 फीडबैक? मुझे लगता है कि धागा इन के रूप के बारे में बात नहीं मिल सकता है, लेकिन शायद यह होना चाहिए 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
}

@ टायरियर IMO को इसके लिए एक अलग हैंडलर बनाने से कोई मतलब नहीं है। इस एपीआई के संभावित उपभोक्ता हमारे रेंडरर होंगे जो कि एक टूलटिप में url प्रदान करते हैं यदि हम लिंक किए गए पाठ को मँडराते हैं, तो नहीं? शायद यह onLinkHover और onLinkLeave लिए पूर्वोक्त हुक के साथ हमारे लिंकफ़ायर का विस्तार करने के लिए समझ में आता है, और उन ansi हाइपरलिंक को संभाला है जैसे हम अभी वेब लिंक के साथ करते हैं?

इस एपीआई के संभावित उपभोक्ता हमारे रेंडरर होंगे जो एक टूलटिप में यूआरएल को प्रस्तुत करते हैं

@ mofux मैं खोज एडऑन की तरह अधिक सोच रहा था, ITerminalOptions.enableAnsiHyperlinks होने का अनुमान है और इसका विवरण क्यों है?

मुझे लगता है कि मौजूदा लिंक एपीआई में विलय होने और ऑप्ट-इन के लिए ITerminalOptions.enableAnsiHyperlinks होने का अनुमान है और इसका विवरण क्यों है?

इस सुविधा का समर्थन करने के लिए एंबेडर्स की कहानी कैसी होगी? लिंक किए गए टेक्स्ट को क्लिक करते समय (अदृश्य) लिंक खोलना संभावित रूप से खतरनाक है - खासकर अगर हम लिंक किए गए URL को कहीं भी नहीं दिखाते हैं

लक्ष्य को दिखाते समय वास्तव में अच्छा है, मुझे नहीं लगता कि "अज्ञात" URL खोलने में कोई समस्या है। चश्मा के नीचे टिप्पणियों में सुरक्षा पहलुओं पर चर्चा की गई है। ब्राउज़र हर समय "अज्ञात" URL खोलते हैं, उदाहरण के लिए जब जेएस कोड होता है जो इसे खोलने से ठीक पहले लक्ष्य को बदल देता है, तो अक्सर उपयोगकर्ता को "अच्छा" URL दिखाने के लिए, लेकिन वास्तव में इसे रीडायरेक्टर के माध्यम से खोलें।

बोले कि ... ऐसा कुछ जो अभी तक मेरे साथ नहीं हुआ है ...

यदि xterm.js एक वास्तविक ब्राउज़र के अंदर चल रहा है, और उस ब्राउज़र का एक नया टैब कहने के लिए लिंक को खोलता है: मुझे लगता है कि Reterer फ़ील्ड के माध्यम से xterm.js का URL लीक करना चिंता का विषय है। Rel = "noreferrer" के लिए वर्तमान समर्थन के बारे में निश्चित नहीं है, लेकिन ऐसा लगता है कि इसका उपयोग किया जाना चाहिए।

होवर टेक्स्ट की इस संबंधित चर्चा को देखें। यह मुद्दा "टूल-टॉप्स" और अन्य माउस-ओवर पॉपअप के साथ आउटपुट के एनोटेटिंग अनुभागों के बारे में है, जो लिंक पर होवर करते समय URL प्रदर्शित करने के समान नहीं है। हालांकि, दोनों वास्तविक होवर पाठ को प्रदर्शित करने के लिए एक ही तंत्र का उपयोग करना चाह सकते हैं। दोनों शायद MouseZoneManager ।

क्या हमारे पास कोई एक्सएसएस विशेषज्ञ हैं जो घूम रहे हैं? शायद हमें एक ऑडिट की जरूरत है, योग्य।

ब्राउज़र सुरक्षा के बारे में मेरे सीमित ज्ञान के लिए xterm.js के साथ मुख्य हमला वेक्टर टर्मिनल / ब्राउज़र सीमा पार करने वाला डेटा है:

• टर्मिनल (डेटा) में ब्राउज़र (जेएस) से XSS
  यह पहले से ही संभव है और एकीकरणकर्ता की जिम्मेदारी का पालन करता है (xterm.js किसी भी तरह से इसे नियंत्रित नहीं कर सकता है)। अंगूठे का नियम - कभी भी टर्मिनल पेज या पीटीआई वेबसोकेट पर किसी भी अविश्वासित स्रोत से स्क्रिप्ट आयात न करें और इस तरह से सिस्टम जो कि मेजबानों को नष्ट कर देता है खो गया है। न अनफ़िल्टर्ड उपयोगकर्ता सामग्री को पृष्ठ में सम्मिलित करने की अनुमति दें और जैसे - मूल रूप से सभी विशिष्ट XSS चीजें, या पेंटी खो जाती हैं।
• ब्राउज़र में टर्मिनल (डेटा) से XSS (JS)
  Thats एक नई गुणवत्ता जिसे हम URL के साथ दर्ज कर सकते हैं, यदि हम यह सुनिश्चित नहीं करते हैं कि टर्मिनल डेटा एम्बेडिंग पेज के जेएस संदर्भ (इस प्रकार टर्मिनल ऑब्जेक्ट स्वयं) तक कभी नहीं पहुंचेगा। यदि संभव हो तो (मान लेते हैं कि एक दूसरे के लिए) एक हमलावर ब्राउज़र पेज तक पहुंच प्राप्त कर सकता है, और इस प्रकार एक टर्मिनल (डेटा) - ब्राउज़र (जेएस) - टर्मिनल (डेटा) हमला करता है। आगे चलकर xterm.js को क्लाउड ऑर्केस्ट्रेटिंग सर्विस पोर्टल्स में अलॉट करता है और एडमिन अलग-अलग मशीनों में टर्मिनल सेशन का इस्तेमाल करता है। बाहर निकलना। एक बार जब अटैकर ब्राउजर पेज पेज पर पहुंच जाता है, तो सभी क्लाउड सेवाएं जो व्यवस्थापक के पास पहुंच जाती हैं, खतरे में पड़ जाती हैं।

सवाल यह है कि क्या यूआरएल के साथ टर्मिनल (डेटा) - ब्राउज़र (जेएस) सीमा पार करने की संभावनाएं हैं? फिर से ब्राउज़र सुरक्षा के बारे में मेरा सीमित ज्ञान यहाँ बहुत मदद नहीं करता है। केवल परिदृश्य मैं सोच सकता हूं कि वे बुकमार्क हैं जो पेज के जेएस में खुद को इंजेक्ट करते हैं। मेरे पास कोई सुराग नहीं है अगर हम हमेशा एक नई विंडो / टैब में केवल खुले सामान से इससे बच सकते हैं (अनुमान करें कि सत्र अभी भी लीक होगा, अगर httpOnly नहीं? वेबसोकेट कनेक्शन के बारे में क्या?) जो मुझे लगता है कि हमें URL को पार्स करना है? और किसी भी "जेएस दिखने वाली सामग्री", ओह प्रिय ...

संपादित करें: ध्यान दें कि वेबसोकेट ब्राउज़र की अधिकांश सुरक्षा सेटिंग्स को याद करते हैं, उनके पास एक विश्वसनीय समान मूल जांच नहीं है (यदि आपको इस लोल की आवश्यकता है तो अजाक्स लंबे मतदान के साथ जाएं)। हम्म ...

बुकमार्क [...] किसी भी "जेएस दिखने वाली सामग्री" पट्टी

मुझे लगता है कि यह केवल "http: //", "https: //", शायद "ftp: //" से शुरू होने वाले श्वेतसूची के लिए एक अच्छा विचार है और कुछ भी अस्वीकार कर सकता है। या बहुत कम से कम स्कीम की कमी के साथ ही "जावास्क्रिप्ट:"।

अपनी हाइपरलिंक्स शाखा में मैंने एक क्लिक पर एक सेटल कॉलबैक फ़ंक्शन के लिए एक पैच https://github.com/PerBothner/xterm.js/commit/b2647b90d301c52229d01720800865a0d39f4bff जोड़ा। यह बदलने की अनुमति देता है कि लिंक कैसे संभाला जाता है। उदाहरण के लिए जब DOMTerm को ls --hyperlink=auto बाद मेरी xterm.js शाखा का उपयोग करने के लिए कॉन्फ़िगर किया गया है, तो ज्यादातर फ़ाइल नामों पर सेटिंग्स के आधार पर फ़ाइल को खोलेंगी।

(चेतावनी दें कि प्रोटोटाइप में कुछ परतदारता है। मुझे नहीं पता कि क्या यह डोमटर्म प्रोटोटाइप के लिए विशिष्ट है।)

ब्राउज़र हर समय "अज्ञात" URL खोलते हैं, उदाहरण के लिए जब जेएस कोड होता है जो इसे खोलने से ठीक पहले लक्ष्य को बदल देता है, तो अक्सर उपयोगकर्ता को "अच्छा" URL दिखाने के लिए, लेकिन वास्तव में इसे रीडायरेक्टर के माध्यम से खोलें।

@egmontkob ब्राउज़रों में आप आमतौर पर एक खोज इंजन की तरह कहीं सुरक्षित से शुरू करते हैं जो आपको बताता है कि डोमेन कब है। टर्मिनलों के लिए आपको कार्यक्रमों पर भरोसा करना होगा (जिनमें से कुछ रिमोट कंटेंट प्रिंट कर सकते हैं), यहां तक ​​कि एक फाइल को भी दुर्भावनापूर्ण लिंक दिखा सकता है। ऐसा लगता है कि डिफ़ॉल्ट रूप से सुरक्षित होना सबसे अच्छा होगा और एक सेटिंग है जो सिर्फ जोखिमों का वर्णन करती है और उपशमन प्रदान करती है।

अपनी हाइपरलिंक्स शाखा में मैंने एक क्लिक पर एक सेटल कॉलबैक फ़ंक्शन के लिए एक पैच

@PerBothner वेबलिंक के ऐडऑन में यहाँ पहले से ही एक हैंडलर है: https://github.com/xtermjs/xterm.js/blob/509ce5fa3a698ee7847411117e9dd6b979b105bf/src/addons/webLink/webLink/webLink/ सेटअप 2 अलग-अलग वेब लिंक हैंडलर।

(बेल्टेड प्रतिक्रिया के लिए क्षमा करें - मैं साइड-ट्रैक हो गया।)

@Tyriar ने लिखा "वेबलिंक्स के ऐडऑन में यहाँ पहले से ही एक हैंडलर है"। समस्या यह है कि WebLinksInit एक ILinkMatcher बनाता है, और दिए गए हैंडलर को एक विशिष्ट ILinkMatcher के साथ जोड़ता है, जिसमें मैच करने के लिए regexes का एक सेट होता है। लेकिन हम एक एस्केप सीक्वेंस द्वारा बनाए गए हाइपरलिंक्स के लिए लिंक-हैंडलर को कैसे निर्दिष्ट करते हैं और इस तरह एक रेगेक्स मैच का परिणाम नहीं है? उस हैंडलर को किसी भी ILinkMatcher या regex के साथ नहीं जुड़े होने के अर्थ में "वैश्विक" होने की आवश्यकता है। WebLinksInit या Terminal.registerLinkMatcher का उपयोग करके वैश्विक / डिफ़ॉल्ट हैंडलर सेट करना काम नहीं करता है।

मुझे ऐसा लगता है कि हम एक की जरूरत है linkHandler टर्मिनल में क्षेत्र - एक होने handler में क्षेत्र ILinkMatcher पर्याप्त नहीं है। और अगर हमारे पास linkHandler फ़ील्ड में Terminal यह समझ में आता है कि हैंडलर रजिस्टरलिंकमैचर द्वारा उपयोग किए जाने वाले डिफ़ॉल्ट हैं। यह मेरा पैच है।

अगर कोई इसके साथ मदद करना चाहता है, तो यहां क्या होना चाहिए:

• यह पता लगाएं कि URL के रूप में लिंक न दिखाने के सुरक्षा निहितार्थ से निपटने के लिए, यह संभवत: सुविधा को चुनने और एक हुक को उजागर करने के लिए है ताकि उपभोक्ता एक पॉपअप दिखा सकें।
• किसी लिंक को खोलने के लिए एक अच्छा एपीआई देखें, हमारे पास पहले से ही लिंक मिलान एपीआई के साथ बहुत कुछ समान है, क्या इसे सामान्यीकृत किया जा सकता है?
• पार्सर में तर्क जोड़ें और लिंक को कहीं स्टोर करें, शायद IMarker s के रूप में?

मेरी हाइपरलिंक शाखा https://github.com/PerBothner/xterm.js/tree/hyperlinks एक प्रारंभिक बिंदु हो सकती है। (हालांकि यह थोड़ा पुराना है इसलिए अब काम नहीं हो सकता है।)

उपरोक्त शाखा की स्थिति क्या है? क्या कोई इस पर काम कर रहा है?
@Tyriar ने अच्छी तरह से आवश्यक चरणों को सूचीबद्ध किया। क्या इनमें से कोई भी कदम उठाया गया है?

@ Jma353 मुझे नहीं लगता कि कोई भी सक्रिय रूप से काम कर रहा है, इसलिए आवश्यक बिट्स को लागू करने के लिए स्वतंत्र महसूस करें।

@ टायरियर मैंने सभी विवरणों के लिए युक्ति नहीं पढ़ी है, लेकिन ऐसा लगता है कि इसे लागू करने में कुछ पार्सर हैंडलर करतब दिखाने वाले, एस्प शामिल होंगे। एक अस्थायी InputHandler.print अधिभार की तरह कुछ। किन्दा अजीब है कि यह इस तरह से बनाया गया है (यह कुछ हद तक पार्सर में खींचता है, एक तथ्य यह है कि अब तक कोई अन्य भागने का क्रम नहीं करता है), लेकिन बीच में प्रिंट हैंडलर को प्रतिस्थापित करके यह संभव होना चाहिए।

@ जार्च हाँ, यह कुछ parser परिवर्तन की आवश्यकता होगी। लिपटे लिंक का आकार बदलना एक ऐसा मामला है जिसे हमें सुनिश्चित करने के लिए भी काम करना होगा।

VS कोड में अब लिंक के लिए विस्तृत होवर दिखाने के लिए समर्थन है, इसलिए इसे हुक करने से समस्या हल हो जाएगी:

यह शर्म की बात है कि यह एक अजीब सीक्वेंस का एक सा है क्योंकि हमारे पार्सर हुक इसे कवर नहीं करते हैं। यदि उन्होंने ऐसा किया है तो पूरी तरह से पार्सर हुक, मार्कर और लिंक प्रदाता एपीआई का उपयोग करके एक ऐडऑन के रूप में किया जा सकता है।

@ तीयर भी # 2751 के साथ विस्तारित

यह शर्म की बात है कि यह एक अजीब सीक्वेंस का एक सा है क्योंकि हमारे पार्सर हुक इसे कवर नहीं करते हैं। यदि उन्होंने ऐसा किया है तो पूरी तरह से पार्सर हुक, मार्कर और लिंक प्रदाता एपीआई का उपयोग करके एक ऐडऑन के रूप में किया जा सकता है।

हाँ, यह एक समस्या है और अगर हम एक प्रिंट हैंडलर हुक को उजागर करेंगे, तो भी एडोन स्तर पर हल नहीं किया जा सकता है। मुझे लगता है कि इसे सीधे कोडबेस और कुछ असाधारण स्थितियों में जाना होगा (जैसे किसी भी गैर प्रिंट कार्रवाई से पहले अंतिम रूप से स्वीकार किए जाने पर कोशिकाओं और इस तरह के URL अंकन को तोड़ देना चाहिए)।