Xterm.js: ハイパーリンクANSIエスケープをサポートする

良いアイデア、PR歓迎！

これが標準になり、構文解析が容易になる可能性があります。
関連する問題： https ：

最大の利点は、長いURLで端末をスパムすることなくテキストをリンクできることです。 たとえば、エラーメッセージのドキュメントに、冗長にすることなくリンクできます。

これは注意して実装する必要があります。リンクにカーソルを合わせると、リンクがどこにつながるかを確認できる必要があります。そうしないと、ユーザーを無意識のうちに悪意のあるサイトにリンクする可能性があります。 これは、電子メールフィッシングではすでに大きな問題です。

たとえば、「login.facebook.com」というタイトルのリンクを作成し、実際にはそれをlogin.faceboook.comにリンクして、ページはまったく同じに見えますが、ログイン時にユーザーのパスワードを保存することができます。

iTerm2は次のようなURLを表示します：

これは、リンクにカーソルを合わせたときにChromeがURLを表示する方法にも似ています。

/これが実装されている場合は、この機能のサポートを検出することを目的とした問題またはPRをsupports-hyperlinksに送信してください。

@jamestalmageこれはおそらくTERM_PROGRAMます。

@ Tyriar-その場合、おそらくこれを実行するコミットと、それが広くなるときのリリースノートにsupports-hyperlinksへの参照を含めるだけです。 他の言語に相当するsupports-hyperlinksがあるかどうかはわかりませんが、ある場合は、おそらくそれらについても言及する価値があります。

概念実証の実装があります。

Links.txt

これらのリンクは実際にはバッファに保存されないため、ウィンドウのサイズを変更すると消えてしまうという根本的な問題があります。 代わりに、リンク情報が保存されているにMouseZoneManagerによってクリアされた_mouseZoneManager.clearAll 。

実際の修正は、バッファの再実装が完了するまで待たなければならないと思います。 サイズ変更時に安定している、セルやセル範囲に注釈を付けるメカニズムが必要です。

（または、このコードベースに慣れていないために、何かが足りないだけかもしれません。）

実際の修正は、バッファの再実装が完了するまで待たなければならないと思います。 サイズ変更時に安定している、セルやセル範囲に注釈を付けるメカニズムが必要です。

@PerBothnerええあなたはおそらく正しいです。 これが出荷可能になる前に考慮する必要があるもう1つのことは、基になるURLがxterm.jsから公開され、埋め込み者がUIに表示できるようにする方法です。 また、セキュリティ上の理由から、デフォルトでオフにすることもできます（URLはデフォルトで表示されないため）。

パッチを更新してブランチにプッシュしました： https ：

ただし、プルリクエストの準備はできていません。前述のさまざまな問題は解決されていません。

これを使用するためのAPIの提案：

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;
}

APIシェイプに関する@ mofux @ jerchフィードバック？ これらの形式について話しているスレッドは見つかりませんが、 setするのが理にかなっているため、 addではなくsetにする必要があります。

また、 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
}

@TyriarIMOこのために別のハンドラーを作成することはあまり意味がありません。 このAPIを使用する可能性が高いのは、リンクされたテキストにカーソルを合わせるとツールチップにURLをレンダリングするレンダラーです。 たぶん、 onLinkHoverとonLinkLeaveの前述のフックを使用してリンキファイアを拡張し、それらのansiハイパーリンクを現在のWebリンクと同じように処理するのは理にかなっていますか？

このAPIを使用する可能性が高いのは、ツールチップでURLをレンダリングするレンダラーです。

@mofux私は検索アドオンのように考えていました。ITerminalOptions.enableAnsiHyperlinksを設定していると思いますが、その理由を詳しく説明しますか？

既存のリンクAPIにマージし、オプトイン用にITerminalOptions.enableAnsiHyperlinksを設定していると思いますが、その理由を詳しく説明しますか？

埋め込み者がこの機能をサポートするためのストーリーはどうでしょうか？ リンクされたテキストをクリックしたときに（非表示の）リンクを開くことは潜在的に危険です-特にリンクされたURLがどこにも表示されていない場合🤔

ターゲットを前もって表示するのは確かに素晴らしいことですが、「不明な」URLを開くことに問題はないと思います。 セキュリティの側面は、仕様の下のコメントで説明されています。 ブラウザは常に「不明な」URLを開きます。たとえば、ターゲットを開く直前にターゲットを変更するJSコードがある場合、多くの場合、ユーザーに「適切な」URLを表示しますが、実際にはリダイレクタを介して開きます。

そういえば...今のところ私には起こらなかったことが...

xterm.jsが実際のブラウザ内で実行されていて、そのブラウザの新しいタブでリンクを開いた場合、[リファラー]フィールドからxterm.jsのURLが漏洩するのは心配なことだと思います。 rel = "noreferrer"の現在のサポートについてはわかりませんが、使用する必要があるようです。

ホバーテキストのこの関連する説明を参照してください。 これは、出力のセクションに「ツールトップ」やその他のマウスオーバーポップアップで注釈を付けることに関する問題です。これは、リンクにカーソルを合わせたときにURLを表示することと同じではありません。 ただし、どちらも同じメカニズムを使用して実際のホバーテキストを表示したい場合があります。 どちらもおそらくMouseZoneManagerを利用するでしょう。

XSSの専門家がぶらぶらしていますか？ たぶん私たちは監査が必要です、笑。

ブラウザのセキュリティに関する私の限られた知識では、xterm.jsを使用した主な攻撃ベクトルは、ターミナルとブラウザの境界を越えるデータです。

• ブラウザ（JS）から端末（データ）へのXSS
  それはすでに可能であり、インテグレーターの責任を負わせます（xterm.jsはこれを決して制御できません）。 経験則-ターミナルページまたはptyWebSocket上の信頼できないソースからスクリプトをインポートしないため、ptyをホストするシステムが失われます。 フィルタリングされていないユーザーコンテンツをページなどに挿入しないでください。基本的にすべての一般的なXSSのものです。そうしないと、ptyが失われます。
• 端末（データ）からブラウザ（JS）へのXSS
  これは、端末データが埋め込みページのJSコンテキスト（つまり、端末オブジェクト自体）に到達しないことを確認しない場合に、URLで入力する可能性のある新しい品質です。 それが可能であれば（少しの間）、攻撃者はブラウザページにアクセスできるため、ターミナル（データ）-ブラウザ（JS）-ターミナル（データ）攻撃を行うことができます。 さらに、xterm.jsがクラウドオーケストレーションサービスポータルで大量に実行され、管理者がさまざまなマシンへのターミナルセッションを使用すると仮定します。 アウトチ。 攻撃者が埋め込みブラウザページにアクセスできるようになると、管理者がアクセスできるすべてのクラウドサービスが危険にさらされます。

問題は、-ターミナル（データ）-ブラウザ（JS）の境界をURLと交差させる可能性はありますか？ ここでも、ブラウザのセキュリティに関する私の限られた知識はあまり役に立ちません。 私が考えることができる唯一のシナリオは、ページのJSに自分自身を挿入するブックマークレットです。 常に新しいウィンドウ/タブでのみ開くことでこれを回避できるかどうかはわかりません（httpOnlyでない場合でも、セッションはリークすると思いますか？WebSocket接続はどうですか？）これにより、URLを解析する必要があると思います「JSに見えるコンテンツ」を削除します。

編集：WebSocketはブラウザのセキュリティ設定のほとんどを見逃していることに注意してください、信頼できる同一生成元チェックさえありません（これが必要な場合はajaxロングポーリングを使用してください）。 うーん...

ブックマークレット[...]「JSに見えるコンテンツ」を削除します

「http：//」、「https：//」、おそらく「ftp：//」で始まるURLのみをホワイトリストに登録し、それ以外は拒否することをお勧めします。 または、少なくともスキームの欠如と「javascript：」をブラックリストに登録します。

ハイパーリンクブランチに、クリック時に設定可能なコールバック関数のパッチhttps://github.com/PerBothner/xterm.js/commit/b2647b90d301c52229d01720800865a0d39f436fを追加しました。 これにより、リンクの処理方法を変更できます。 たとえば、 DomTermがls --hyperlink=auto後にxterm.jsブランチを使用するように構成されている場合、ほとんどのファイル名で設定によっては、htmlファイルでデフォルトのブラウザーでファイルが開き

（プロトタイプには多少のフレークがあることに注意してください。それがDomTermプロトタイプに固有のものであるかどうかはわかりません。）

ブラウザは常に「不明な」URLを開きます。たとえば、ターゲットを開く直前にターゲットを変更するJSコードがある場合、多くの場合、ユーザーに「適切な」URLを表示しますが、実際にはリダイレクタを介して開きます。

ブラウザの@egmontkobは、通常、検索エンジンのような安全な場所から開始します。検索エンジンは、ドメインがいつであるかを非常に明確に示します。 ターミナルの場合、プログラムを信頼する必要があり（その一部はリモートコンテンツを印刷する可能性があります）、ファイルをキャットするだけでも悪意のあるリンクが表示される可能性があります。 デフォルトで安全であり、リスクを説明し、軽減策を提供するだけの設定を設定するのが最善のようです。

ハイパーリンクブランチに、クリック時に設定可能なコールバック関数のパッチPerBothner @ b2647b9を追加しました。

@PerBothnerはすでにwebLinksアドオンにハンドラーがあります： https ：

（応答が遅れて申し訳ありません-私は脇道に追いやられました。）

@Tyriarは、「webLinksアドオンにはすでにハンドラーがあります」と書いています。 問題は、webLinksInitがILinkMatcherを作成し、指定されたハンドラーを、一致する正規表現のセットを含む特定のILinkMatcherに関連付けることです。 しかし、エスケープシーケンスによって作成され、正規表現の一致の結果ではないハイパーリンクのリンクハンドラーをどのように指定するのでしょうか。 そのハンドラーは、ILinkMatcherまたは正規表現に関連付けられていないという意味で「グローバル」である必要があります。 webLinksInitまたはTerminal.registerLinkMatcherを使用してそのグローバル/デフォルトハンドラーを設定することは機能しません。

我々が必要と私には思えるlinkHandler持つ-ターミナル内のフィールドhandlerでフィールドをILinkMatcher十分ではありませんが。 また、 TerminalにlinkHandlerフィールドなどがある場合は、そのハンドラーをregisterLinkMatcherで使用されるデフォルトにするのが理にかなっています。 これは私のパッチが行うことです。

誰かがこれを手伝いたい場合は、次のことが必要です。

• リンクがURLとして表示されないことによるセキュリティへの影響に対処する方法を理解します。これはおそらく、機能をオプトインしてフックを公開し、消費者がポップアップを表示できるようにするためです。
• リンクを開くための優れたAPIを見つけてください。リンクマッチャーAPIと非常によく似たものがすでにありますが、これを一般化できますか？
• ロジックをパーサーに追加し、リンクをどこかに保存します。おそらくIMarker sとして？

私のハイパーリンクブランチhttps://github.com/PerBothner/xterm.js/tree/hyperlinksが出発点になります。 （少し古いので、もう動作しないかもしれませんが。）

上記の支店の状況はどうなっていますか？ 誰かがこれに取り組んでいますか？
@Tyriarは、必要な手順をうまくリストしました。 これらの手順のいずれかが実行されましたか？

@ Jma353誰もがこれに積極的に取り組んでいるとは思わないので、必要なビットを自由に実装してください。

@Tyriar仕様の詳細をすべて読んだInputHandler.printオーバーロードのようなもの。 このように作成されているのはちょっと奇妙です（これは、端末の状態をパーサーにいくらか引き込みます。これまでのところ、他のエスケープシーケンスは実行されていません）が、その間に印刷ハンドラーを置き換えることで実行できるはずです。

@jerchええ、パーサーの変更が必要になります。 ラップされたリンクのサイズ変更は、確実に機能するようにする必要がある場合です。

VS Codeは、リンクの詳細なホバーの表示をサポートするようになったため、これをそれに接続すると問題が解決します。

パーサーフックがカバーしていないので、少し奇妙なシーケンスであるのは残念です。 もしそうなら、これはパーサーフック、マーカー、リンクプロバイダーAPIを使用してアドオンとして完全に行うことができます。

@ Tyriar ＃2751でも、拡張attrストレージを使用して、URLのものをバッファーセルに注釈を付けることができます。

パーサーフックがカバーしていないので、少し奇妙なシーケンスであるのは残念です。 もしそうなら、これはパーサーフック、マーカー、リンクプロバイダーAPIを使用してアドオンとして完全に行うことができます。

ええ、それは問題であり、プリントハンドラーフックを公開したとしても、アドオンレベルでimhoを解決することはできません。 これは、コードベースに加えていくつかの例外的な条件に直接入る必要があると思います（ファイナライザーが承認される前の非印刷アクションは、セルのURLマーキングなどを壊すはずです）。