[WIP] Websocket authentication for preview #1093
Conversation
|
I have pinged Enter-tainer. He will give first review when he schedule a time. |
I haven't read code yet. Does compat mode means the
I cannot remember it clearly. Typst-preview starts from vscode webview and then it goes into browser and finally integrated into tinymist. I guess this explains why we do |
| /// | ||
| /// This function takes an owned `HyperWebsocketStream` to avoid accidental misuse elsewhere before authentication. | ||
| /// | ||
| /// TODO: This is a basic challenge response authentication with nonces. Is there something more standard we could use? |
|
I just remembered that we actually have 2 websockets here(at least in typst-preview). The "control plane" and the "data plane". This exists because in the very first, typst-preview is not a lsp, so it cannot directly receive buffer updates in vscode. Therefore a websocket server is for sending control messages between editor(vscode) and typst-preview binary. And the data plane server send typst document data to browser/webview for previewing. |
By compat I meant The websocket authentication should work fine with the
Right. For I actually have a related question: There are also two websockets in the |
|
Sorry but I completely forget what does typst-preview compat mode do. @Myriad-Dreamin could you please give more input on this? Thanks! From what I understand so far, people should be using
I believe so. typst-preview.nvim use websocat to connect to control plane. This is documented in https://enter-tainer.github.io/typst-preview/editor.html |
Ah, so the neovim part lives in a different repository. Requiring authentication for the control plane websocket is a breaking change for that neovim package then, I guess. How should we handle this? Looking at that code, it also seems to read the server urls to connect to from the As a possible alternative: @SylvanFranklin recently said to be working on using lsp workspace commands to start the preview etc. for neovim. In that case, neovim would no longer need the control plane server. (cc @chomosuke) |
mirroring HTTP digest authentication
So users can infer how to connect to the control plane server when using `typst preview` cli.
That would be cool. Previously we use websocket because we don't have a good editor/server connection. But as typst-preview has been integrated into tinymist, we could use lsp commands to achieve the same thing. |
It is specific to compatible with the old typst-preview extension. They are still in the repository and built per CI and release. |
|
typst-preview.nvim is happy to take this breaking change to the face and upgrade to using lsp commands (or whatever the new way of starting preview is). Can probably make a new plugin called tinymist.nvim and deprecate the old plugin, or just a new version. |
@tmistele We can add an option to enable/disable the authentication. It should be good to continue warn if the authentication is not enabled. I believe some user will finally find and report the warning log in the next few years. Of course, we could also open an issue to some known downstream, like typst-preview.nvim and typst-preview.el (emacs). |
Hey @tmistele I have paused working on this because I wasn't sure about the status of typst-preview.nvim relating to tinymist. |
I would be fine with a configuration option as long as the default is to turn authentication on. That would of course still break downstream packages. But such downstream packages then have a very easy and quick temporary fix (just add a command line flag which turns authentication off). This should give downstream packages a good way to transition (add the command line flag until they added proper authentication support). Does that sound good to you @Myriad-Dreamin ? I agree we should open issues to downstream packages so they're aware. |
thanks for clarification. i think we can safely remove them when it's time. |
This adds authentication so that users don't have to worry about a) third parties being able to connect to the tinymist servers on 127.0.0.1 (browsers allow any website to do that) and b) third parties impersonating the tinymist server, potentially making the frontend html/javascript leak information (e.g. on multi-user systems).
This is not ready yet. But I thought I'd post it so you can comment on the overall approach.
This seems to work for me but I haven't tested everything. Especially the VSCode extension I have tested only very superficially. And I have not at all tested the "compat" integration with
typst-preview.Some random notes and questions:
typst-previewwill not be updated to add support for authentication? For now, I've built in an escape hatch to avoid authentication for the "compat" preview mode (completely untested!). How do you think this should be handled? It would be easiest to just not support thetypst-previewcompat mode but I guess you don't want to do that yet?replace(...)ing ports and user settings directly into the html. These settings are now passed in as part of URL that's opened in the browser (likehttp://127.0.0.1:23625/#param=value). That code restructuring makes it more immediately obvoius that there's nothing interesting in the html for an attacker.Unfortunately, the vscode webview panel doesn't seem to support setting a location hash (or maybe it does and I didn't figure out how?), so I've built in an escape hatch for the VSCode webview panel where the settings are now
replace(...)ed into the html. That's somewhat unfortunate, but not a problem from a security point of view because the vscode webview panel cannot be accessed from outside vscode I think.typst-webview-assets/in the frontend html. That didn't seem to have any effect in my tests. Does this code ever do anything?cc @Myriad-Dreamin