With the implementation of the HTTP proxy it would be great to have an environment variable VSCODE_HTTP_REFERER available to build custon URLs for proxied webview requests.
This feature helps solving REditorSupport/vscode-R#275. The existence of such an environment variable also allows to differentiate a local (VS Code) installation from a server (code-server) installation.
I experimented with replacing 127.0.0.1:<port> with /proxy/<port> before writing out the webview HTML which worked for the PlatformIO extension but then it tried to make a websocket connection against the root (/wsrpc) instead of being relative (/path/<port>/wsrpc) which obviously won't work.
So the environment variable sounds like a reasonable way to solve this. Either that or require that extensions be aware that they might be behind a proxied base path and make connections accordingly. There might be other cases I haven't considered though so the environment variable seems like the most flexible.
Oh right the name. I think CODE_SERVER_HTTP_REFERER makes sense.
@code-asher Keeping in mind other derivatives of VS Code (e.g. Eclipse Theia) it would make sense to tend towards VSCODE_HTTP_REFERER.
👉 The name of their ancestor; a common name to implement the functionality for Ikuyadeu/vscode-R in all of VS Code derivatives - if their collaborators decide to do so.
Please use VSCODE_HTTP_REFERER then, as there are already other environment variables in code-server prefixed with VSCODE_ referencing to its ancestor; e.g. VSCODE_GIT_IPC_HANDLE, VSCODE_GIT_ASKPASS_NODE, etc.
Should we be using the actual referer header here (or host actually I suppose)? Or do we want the proxy path? If it needs to be general for other editors I'm thinking they might not all have /proxy or might do it differently so maybe we need something like VSCODE_PROXY_URI or something like that, perhaps with {port} in it.
Then if the user has sub-domain proxies enabled we could set it to {port}.mydomain.com and if they don't we could set it to mydomain.com/proxy/{port}. And if the environment variable already exists we wouldn't override it so users could provide their own proxy through Caddy, NGINX, etc.
Otherwise we might need to use CODE_SERVER_HTTP_REFERER so extensions can tell the difference between editors and select the URL appropriately.
Activity
kylecarbs commented on Apr 14, 2020
Neat. I don't think we have this ATM.
Thoughts @code-asher ?
code-asher commented on Apr 15, 2020
I experimented with replacing 127.0.0.1:<port> with /proxy/<port> before writing out the webview HTML which worked for the PlatformIO extension but then it tried to make a websocket connection against the root (/wsrpc) instead of being relative (/path/<port>/wsrpc) which obviously won't work.
So the environment variable sounds like a reasonable way to solve this. Either that or require that extensions be aware that they might be behind a proxied base path and make connections accordingly. There might be other cases I haven't considered though so the environment variable seems like the most flexible.
code-asher commented on Aug 3, 2020
We should also make this environment variable available to the terminal (in addition to extensions), see #1939.
benz0li commented on Jun 13, 2021
@code-asher Any timeframe on this issue? Does the name tend towards VSCODE_HTTP_REFERER or CODE_SERVER_HTTP_REFERER?
The project collaborators at Ikuyadeu/vscode-R might give another go at REditorSupport/vscode-R#275 while working on REditorSupport/vscode-R#358.
code-asher commented on Jun 14, 2021
code-asher commented on Jun 14, 2021
benz0li commented on Jun 14, 2021
@code-asher Keeping in mind other derivatives of VS Code (e.g. Eclipse Theia) it would make sense to tend towards VSCODE_HTTP_REFERER.
👉 The name of their ancestor; a common name to implement the functionality for Ikuyadeu/vscode-R in all of VS Code derivatives - if their collaborators decide to do so.
Agreed?
benz0li commented on Jun 14, 2021
Alternaively HTTP_REFERER; neutral, not mentioning a product name.
code-asher commented on Jun 14, 2021
That makes perfect sense to me! My vote would be for HTTP_REFERER I think but I'm good with either one.
benz0li commented on Jun 15, 2021
Please use VSCODE_HTTP_REFERER then, as there are already other environment variables in code-server prefixed with VSCODE_ referencing to its ancestor; e.g. VSCODE_GIT_IPC_HANDLE, VSCODE_GIT_ASKPASS_NODE, etc.
Thank you!
code-asher commented on Jun 15, 2021
Should we be using the actual referer header here (or host actually I suppose)? Or do we want the proxy path? If it needs to be general for other editors I'm thinking they might not all have /proxy or might do it differently so maybe we need something like VSCODE_PROXY_URI or something like that, perhaps with {port} in it.
Then if the user has sub-domain proxies enabled we could set it to {port}.mydomain.com and if they don't we could set it to mydomain.com/proxy/{port}. And if the environment variable already exists we wouldn't override it so users could provide their own proxy through Caddy, NGINX, etc.
Otherwise we might need to use CODE_SERVER_HTTP_REFERER so extensions can tell the difference between editors and select the URL appropriately.
26 remaining items
Add VSCODE_PROXY_URI to resolver env
benz0li commented on Sep 16, 2021
FYI https://vscode-r.jupyter.b-data.ch has been updated:
jsjoeio commented on Sep 16, 2021
Just a heads-up - we've had a bunch of other priorities come up and haven't been able to get to this yet (but we will soon)
benz0li commented on Jan 5, 2022
@code-asher coder/vscode#37 sets mydomain.com/proxy/{{port}} instead of mydomain.com/proxy/{port}.
ℹ️ Tested with the latest release artefacts.
Why the double brackets?
benz0li commented on Jan 5, 2022
Since REditorSupport/vscode-R#803 already in place, this will lead to errors with the current version of the R extension.
I suggest the following:
In the meantime and before releasing code-server v4.0.2:
ℹ️ This makes sure, that both versions (single brackets, double brackets) are handled correctly.
code-asher commented on Jan 5, 2022
Ahh I did not realize this was already implemented in vscode-R!
I used double braces to match VS Code's own templating scheme they use with webview URIs. I will go ahead and move back to one.