Plugin API

[code-asher]

code-server currently has a plugin API but it is intentionally not documented or supported.

Some questions for discussion, feel free to add more:

1. Should code-server even have a plugin API?
2. What sort of things should it be able to do? (Add endpoints, override endpoints, customize authentication, etc.)
3. Should we scrap the current plugin system and implement it as a VS Code extension instead? (Likely will require patching VS Code's extension API.)
4. Or should we re-implement the plugin API separately from VS Code?
5. Or should we keep the plugin API as-is and expand on it?
6. Should the plugin API be Express-based as it currently is?
7. What specifically should the plugin API look like?

[code-asher]

My thoughts:

1. Yes, it lowers the cost of adding features.
2. Add arbitrary middleware (unsure of security implications though) and add endpoints but not override existing ones.
3. Since we are moving closer to VS Code with the fork anyway I think it might make a lot more sense to implement as a built-in VS Code extension instead of using a bespoke plugin system even if it does mean maintaining a bigger patch.
4. No, see 3
5. No, see 3
6. It depends on whether the next form of code-server will be using Express or not. But since Express is convenient and a well-known package I think it might be wise to keep using it.
7. TBD

[code-asher]

Next steps:

1. Look into any existing VS Code authentication code and see if it is anything like what we need or if we can tweak it to make it work for us.
2. If that is a bust then put up a proposal for the required API changes.

[code-asher]

I should also mention that I think the first will only work once we fully convert to the fork. Right now we do not even spawn VS Code until we need it so we cannot rely on it for authentication. So we may need to punt on actual execution until that work is completed.

[jsjoeio]

Right now we do not even spawn VS Code until we need it so we cannot rely on it for authentication. So we may need to punt on actual execution until that work is completed.

Ahh good point. Okay we'll reconsider this once we convert to the fork.

[sdissegna-maystreet]

A problem I see with using vscode extensions for auth, is that extensions are activated on each user connection, and only after the main workbench is already working and a websocket connection has already been established. At this point it's way too late to block unauthorized users, as vscode is already usable while extensions are loading. An unauthorized user could have already opened a terminal before the extension is ready. If the user is not authorized, you'd then have to forcefully close the active websocket.

A separate auth system would be a lot simpler. vscode extensions are designed to be controlled by the main workbench (it's the workbench that decides if an extension should even run, and when), while you'd want authentication to be the one in control of the rest of the system.

[code-asher]

That is a really, really good point!

Looks like we will need to preserve code-server's own plugin system and implement auth that way. Or we could scrap the plugin system and only support authentication modules.