Parse deep links sent to Connect

[ravicious]

• Part of Implement in-app logic for a deep link to Connect My Computer #32188.

This PR builds on top of #33637. After receiving an URL, we want to parse it and pass the result of it to the frontend app. This PR implements just the parsing.

This PR doesn't show it, but we generally want to send the whole parsing result to the frontend app. This way in case of any problems the frontend app can show a relevant notification rather than just doing nothing. For example, imagine in v15 we add support for another deep link. If someone with v14 clicks on it, we should display some kind of an error instead of just doing nothing. This will be done in a subsequent PR but I just wanted to explain the structure of the code in this PR.

I had to install whatwg-url to parse URLs. That's because the implementation varies wildly between different implementations, especially when using custom protocols. Since uri.ts can be potentially used both on the Node.js side as well as the Chromium side, I wanted to play it safe.

Different kinds of URIs

One thing which I had hard time navigating is that what we call URIs in uri.ts are Connect's identifiers for various things, e.g. a specific SSH server on a specific leaf cluster or a specific tab in the app etc. Those identifiers take the form of just the path of an actual URI, e.g. /clusters/foo.cloud.gravitational.io/dbs/postgres-prod.

This PRs adds support for search params to some of those URIs. In case of the Connect My Computer deep link, we want to be able to pass the username so that if the user is not logged in already, we can prefill the login form.

So this notion of a URI is somehow different than what is considered a URI (or rather a URL) when dealing with deep links. The actual deep link URLs will follow the format of teleport:// + Connect's internal URI format, so for example teleport:///clusters/foo.cloud.gravitational.io/connect_my_computer. The format is totally up to us, as long as it's understood as valid by browsers.

I chose this format because the format of the path follows the format already established by Connect. Since it's the first time we need to use some kind of a word separator in our URIs, I chose the underscore as the word separator. This is because we already use the underscore for resource kids and those resource kinds are used in ResourceIDs. If we were ever to coalesce ResourceIDs with our URIs, I guess it's best to keep the word separator the same.

---

Here's a fiddle with deep links you can use for testing. Remember that this will only work if you installed a packaged app.

[ravicious]

Omg, I completely missed the fact that the import of whatwg-url in uri.ts impacts any other test which imports uri.ts (and thus whatwg-url).

I'll have to come up with a better solution than selectively changing jest-environment through a top level comment.

See:

• ReferenceError: TextEncoder is not defined jsdom/whatwg-url#209 (comment)
• Add support for TextEncoder and TextDecoder jsdom/jsdom#2524 (comment)

[ibeckermayer]

Omg, I completely missed the fact that the import of whatwg-url in uri.ts impacts any other test which imports uri.ts (and thus whatwg-url).

I'll have to come up with a better solution than selectively changing jest-environment through a top level comment.

See:

• ReferenceError: TextEncoder is not defined jsdom/whatwg-url#209 (comment)
• Add support for TextEncoder and TextDecoder jsdom/jsdom#2524 (comment)

I'v only glanced at this so I'm not sure if this is relevant, but since you linked to jsdom's lack of TextEncoder in relation to tests, this might be useful to you:

teleport/web/packages/teleport/src/lib/tdp/codec.ts

Lines 24 to 26 in 851b51e

	// This is needed for tests until jsdom adds support for TextEncoder (https://github.com/jsdom/jsdom/issues/2524)
	window.TextEncoder = window.TextEncoder || TestTextEncoder;
	window.TextDecoder = window.TextDecoder || TestTextDecoder;

[ravicious]

@ibeckermayer Thanks for the tip, I didn't bother to check if we're already dealing with this problem in our codebase!

I believe the issue is on the part of Jest, not jsdom (see jsdom/jsdom#2524 (comment)). I couldn't find a good fix though so for now I'm probably going to use the same approach.

Edit: Addressed that in #33683.

[gzdunek]

I agree with the decision on links format.

[public-teleport-github-review-bot]

@ravicious See the table below for backport results.

Branch	Result
branch/v14	Create PR