fix(client): dynamic key config parsing regression

[jyyi1]

This PR fixes a regression caused by #2192 , where the dynamic key JSON fields server and server_port were ignored.

The Go code now accepts both host+port and server+server_port.

The following screenshots are taken when using this key for test : https://github.com/jyyi1/jyyibin/raw/main/keys/unreachable . We expect a ServerUnreachable error, instead of a UnexpectedPluginError.

Expected (Left) v.s. Current (Right)

[sbruens]

Can you add a regression test for this?

[fortuna]

This is a launch blocker

[fortuna]

Having many ways to express the same thing in the code is a pain. Please don't.
That's convenient for providers, but makes it hard to write correct code, as evidenced by the bug you are trying to fix. It's also a pain for things like getting the host or address from the config.

We need to normalize the config as soon as we get it, so all our code works with a single single way to represent the config.

I'm in the process of normalizing the config already: #2203

Please revert this change to the Go code and fix in the TS code. BTW, what changed that broke this? I couldn't pinpoint in my PR.

[jyyi1]

Here is the code that broke the behavior: https://github.com/Jigsaw-Code/outline-apps/pull/2192/files#r1750971442

But should TS code care about the format of the config? I think TS will only treat it as an opaque string, and pass this string to Go. So in the end, Go will be the single source of truth that understands the config format.

We can align with the Shadowsocks format of server+server_port, and get rid of the internal host+port.

[fortuna]

Unfortunately TS needs to know about the config for a few reasons:

• to validate on adding keys
• to extract the server name for display
• to resolve the server name on Electron
• to access tunnel configuration in the application-specific code

We won't be getting rid of those immediately. We may move some of that to Go, but it will require a new Go target. For now, let's stick to TS, and pass the normalized config to Go.

For the issue you are trying to fix, let's fix where we parse the JSON in Typescript.

[fortuna]

This is very confusing. De we even support host + port? Is that documented anywhere?

[jyyi1]

This is very confusing. De we even support host + port? Is that documented anywhere?

No, we only publicly support server+server_port. The host+port is the internal format.

[fortuna]

I'll fix the bug and a dedicated PR, don't worry.

[jyyi1]

Close this in favor of #2204