impl: fall back to CODER_HEADER_COMMAND when the header command setting is blank - #600
impl: fall back to CODER_HEADER_COMMAND when the header command setting is blank#600folbricht-ant wants to merge 2 commits into
Conversation
| // requests. The command must output each header as `key=value` on its own | ||
| // line. The following environment variables will be available to the | ||
| // process: CODER_URL. | ||
| // process: CODER_URL. If blank, the CODER_HEADER_COMMAND environment |
There was a problem hiding this comment.
I have a couple of thoughts here. First I think mentioning CODER_URL might have been a mistake (from the past). We are not using that variable to resolve the header command. Now if the header command script uses it, then that is an implementation detail that should not leak here.
Second, the way it is phrased right now, one can understand that we fallback to CODER_HEADER_COMMAND if CODER_URL is empty. Right?
I would simply rephrase that the whole thing falls back to the CODER HEADER COMMAND env if available and if the user setting is empty, with no mention of CODER UL.
Everything else looks 👍
There was a problem hiding this comment.
Good point — done in a66796c: dropped the CODER_URL mention and reworded so the fallback clearly refers to the setting ("When this setting is blank, the CODER_HEADER_COMMAND environment variable is used instead, if set"), both here and in the settings UI text. Mirrored the same wording in coder/coder-jetbrains-toolbox#350.
…ng is blank (#350) Same change as coder/jetbrains-coder#600 for the Toolbox plugin: `CoderSettingsStore.headerCommand` falls back to the `CODER_HEADER_COMMAND` environment variable when the stored setting is empty, matching the Coder CLI and the VS Code extension ([`src/settings/headers.ts`](https://github.com/coder/vscode-coder/blob/main/src/settings/headers.ts)), and following the existing `sshConfigOptions` / `CODER_SSH_CONFIG_OPTIONS` fallback in the same class. An unset variable still yields `null`, so the default is unchanged; an explicitly configured setting still wins. README settings entry and the `ReadOnlyCoderSettings` doc updated. Test: `CoderSettingsTest.testHeaderCommand` (store / env / precedence), mirroring `testSSHConfigOptions`.
2 participants
The Coder CLI reads
CODER_HEADER_COMMANDfrom the environment, and the VS Code extension falls back to it whencoder.headerCommandis unset (src/settings/headers.ts). The Gateway plugin only honours its own setting, so on deployments behind an authenticating proxy every user has to paste the command into Settings by hand even when their environment already carries it.This makes
CoderSettings.headerCommandfall back toCODER_HEADER_COMMANDwhen the setting is blank — the same patternsshConfigOptionsalready uses withCODER_SSH_CONFIG_OPTIONS, through the existingEnvironmentseam. All consumers (REST client headers, the CLI exec environment, the--header-commandwritten into the SSH config) read through that getter, so no call sites change. The settings UI comment now names the variable, like the SSH-options one does. An explicitly configured setting still wins.Test:
CoderSettingsTest.testHeaderCommand(state / env / precedence), mirroringtestSSHConfigOptions.Toolbox counterpart: coder/coder-jetbrains-toolbox#350