Custom auth headers in remote HTTP connections

[rynorris]

I'm trying to set up the T3 Code mobile app for developers at my company, connecting to centrally hosted developer VMs.

The problem we have is that those developer VMs require a special auth session token to be passed in a header. They sit behind [Coder](https://coder.com), and Coder's port proxy rejects any request without a Coder-Session-Token header, before it reaches T3 Code. The mobile app can't send that header today, so pairing never reaches the server.

Coder isn't the only proxy like this. Cloudflare Access service tokens (CF-Access-Client-Id and CF-Access-Client-Secret) and Google IAP (Proxy-Authorization) work the same way: the client sends a static credential in a header on every request.

Proposal: let a saved connection carry extra request headers, which the app sends with every request to that connection's address.

• Scope: headers go only to the exact origin they were saved for. They're never sent to routes the server reports later, or to T3 Connect, and only over HTTPS.
• Storage: values live with the connection's credential in the keychain, not in the connection list.
• Coverage: API requests and the WebSocket, plus the native loaders that accept headers: images, file downloads and video. React Native's WebSocket accepts headers, and expo-image, expo-file-system and expo-video all take a headers option.
• Authorization stays T3's: the app refuses a custom Authorization header, since T3 Code uses it for its own token.
• Editing: headers can be changed on a saved connection without pairing again, because these credentials expire on their own schedule.
• Errors: when the proxy rejects a request (a 401 or a redirect to a login page), the app should say the proxy in front of the server rejected it. Otherwise it reads as "the server didn't answer".

Out of scope:

• WebViews. They send headers only on the first page load, so HTML and PDF previews would still fail behind these proxies. A cookie could cover them later.
• The web client. Browsers can't set headers on a WebSocket, and browser users already get the proxy's login cookie.
• Desktop. Its remote connections could use the same setting, but that can come later. SSH is a good workaround for desktop already.

Open question: should a pairing link be able to carry these headers, so one QR code sets up both? It would save users a step, but it puts a second secret in the link.

We have this working in a fork, but our patch is a bit specific to our setup. That said, if a general solution could land upstream, would not to not need to maintain the patch.