base url support

[chartera]

It would be great to use it at another HTTP path, instead of /.
I wanna run it behind proxy and not setup a separate sudomain for it.

[ffleandro]

+1 on this

I came here exactly looking for this.

[jeanp413]

@chartera @ffleandro The purpose of this project is to do the minimal changes on upstream code, for this feature request you should open an issue in upstream repo https://github.com/microsoft/vscode/issues
Having said that, some time ago @wrexroad was looking to do this too, he needed to update some files and I think he got it working, you can take a look at this commit https://github.com/wrexroad/openvscode-server/commit/e89a148d79e53420dbb53c23e1e932d701a839b3
You can build the release version using yarn && yarn gulp vscode-reh-web-linux-x64-min

[wrexroad]

I did get it working for the most part but I'm honestly not sure if that commit has all of the needed changes. A lot of what I did was hacking on the minified js then finding the relevant bits to change in the source. I had planned to figure out exactly what needed to be changed and send the appropriate pull requests once I had I working, but became distracted with other work. I will get back to it and put together a pull request (hopefully) by next week.

It looks like the changes could be easily made upstream, but if they aren't receptive I think the maintainers here should consider implementing something. It would be a pretty minor patch and it would be more value to the users of code-sever than upstream code.

[wrexroad]

For what it's worth I did spend some time trying to get this done last week, but ran out of time. Turns out doing things right takes more time than just making something work for my own purposes... I should have more time in a day or two to work on it again.

[jeanp413]

I've seen some commits recently microsoft#147311 microsoft#148707 that I think will enable this in the next release.
I have not tested it yet but I think you'll only need to change this line https://github.com/microsoft/vscode/blob/d9e91c33351c051876c731485a0c47a5852b904b/src/vs/platform/remote/common/remoteHosts.ts#L34 and set it your desired path

[TiemenSch]

I've been trying to work around this by installing nginx in the Docker image, but I'm struggling to get it to work with some rewrites or redirects as a temporary workaround. Anyone got that to work?

[jhgoebbert]

I've seen some commits recently microsoft#147311 microsoft#148707 that I think will enable this in the next release. I have not tested it yet but I think you'll only need to change this line https://github.com/microsoft/vscode/blob/d9e91c33351c051876c731485a0c47a5852b904b/src/vs/platform/remote/common/remoteHosts.ts#L34 and set it your desired path

What if that path dynamically changes depending on the user and other things? This looks to me as if the path must be fixed.
I ask this question because I would like to integrate OpenVSCode-Server in JupyterLab - see #371 - which users can start by logging in through JupyterHub. In that case a URL would look like:
https://jupyter-jsc-staging.fz-juelich.de/user/j.goebbert.fz-juelich.de/de47c0193b364c36b9da34e681f14911/openvscodeserver
which depends on the user-id and some hash and therefore changes with every new login & user.

This are the errors from the current version 1.68.1:

[kathoef]

I also stumbled across this problem... maybe one should mention that there is also a Visual Studio Code distribution code-server, which has patches applied (see also these search results) that make Visual Studio Code accessible on arbitrary base URLs, i.e. behind reverse proxies such as jupyter-server-proxy. I think, I will be using that one for now.

[jhgoebbert]

Yes, this is definitely an option. At the moment this does not work yet for other reasons:

1. Support proxying to a server process via a Unix socket jupyterhub/jupyter-server-proxy#337 (comment)
2. Add GET authentication coder/code-server#2428

[rokroskar]

@jhgoebbert @kathoef running code-server behind the jupyter-server-proxy works - but did you have some other aspect of the functionality in mind that is currently missing?

[jhgoebbert]

@rokroskar Perhaps I was not specific enough,
but does it now allows to run behind a JupyterHub + jupyter-server-proxy setup?

At least until end of June it was not possible to run a code-server behind a JupyterHub + jupyter-server-proxy because it did not like the use of a configurable https proxy which modifies the base url: #320 (comment)

[rokroskar]

@jhgoebbert if you're talking about code-server (i.e. as per the comment by @kathoef above) then yes - we've been using it for a while now and it mostly works. Often the jupyter/python extension breaks because of some version incompatibility which requires us to do some maintenance. We use the little jupyter-server-extension wrapper: https://github.com/betatim/vscode-binder. You can find the simple script we use here. You can see an example project here.

We would prefer to use vscode directly to avoid issues with extensions, which is why I'm following this thread ;)

[jhgoebbert]

Thank you @rokroskar
I am wondering if this kind of setup is secure on a multi-user system like we have. There is no access-token or password required in the solution of https://github.com/betatim/vscode-binder so any user who has access to the specific port on which the vscode is listening has full control over some others account. 🤔
Using a Unix socket instead of a port can solve this issue - but jupyter-server-proxy/tornado does not support it, yet. Or I would need to start vscode with an access token in the URL (which would be the simplest solution). I will give it another try in the next weeks 👍

[mering]

Upstream added support for --server-base-path in microsoft#202491. IIUC this could allow much smaller patches to get this running behind a proxy.

[jeanp413]

@mering you can use the openvscode-server-insiders release or wait until the next stable release which should be released early april

[jeanp413]

closing as it got implemented upstream

[mering]

As I noted in microsoft#202491 (comment), this does not add the necessary functionality to work behind a proxy which this ticket is about.

[mering]

@jeanp413 can you please re-open as the requested feature is not implemented upstream. Only some other functionality which could allow a smaller downstream patch.

[jeanp413]

This issue is about base path support which the upstream PR added, any additional feature request should be done in the upstream repo as noted in my previous comment #320 (comment)

[mering]

Quoting the issue description:

I wanna run it behind proxy and not setup a separate sudomain for it.

I tried to achieve exactly this (proxy which redirects /subpath to container:port/) with the latest insiders build and the new flag but couldn't get it working (and it was confirmed by upstream that this use case is not supported).

@jeanp413 so can you please re-open this issue?

[Fhwang0926]

#336 (comment)

in case, using dynamic port expose with docker container, using reverse proxy by nginx

[mering]

I created microsoft#210399.