-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stabilize the Mutagen daemon API for third-party usage via a more portable transport #38
Comments
I should preface this by saying that I'm also working on a GUI for Mutagen, though the code is not yet public. I think I'll have a beta version out by November. There is actually already a Mutagen daemon API which is used by the Mutagen commands ( https://github.com/havoc-io/mutagen/blob/master/pkg/service/daemon/daemon.proto For what you want to do, I think you'd only need the session service. Right now the communication with this service is performed via UNIX domain sockets on POSIX systems and Named Pipes on Windows. I've intentionally avoided using any sort of TCP-based transport just because of the inability to secure it with OS-level permissions. A raw local TCP socket is bad enough because it's going to be exposed to anybody on the local machine. A websocket is significantly more difficult to secure because it's going to be available to any webpage you visit. Websockets aren't restricted by CORS, and although Chrome has blocked websocket access to localhost, I think it's one of the only browsers to do so. Thus, any webpage you visit can open a connection to If you're thinking about building such an interface through something like Electron or NW.js, then you have a few more options. I believe the Node.js gRPC bindings allow you to use UNIX domain sockets, though I don't know about Windows Named Pipes. In fact, I think Go may be the only gRPC implementation where you can use Named Pipes at the moment, but there are requests to add it to core gRPC (e.g. here and here). I think that you'd be best off continuing to use gRPC, because a few of the session API calls (e.g. If you really want to go the websocket route, e.g. because you want to go through your browser, you could build a little Go program that would act as a proxy to the daemon, possibly using one websocket connection per call to provide support for streaming. You'd probably be in a better position to do this anyway since you could manage sending the necessary authentication information between the front-end and the websocket. But I still think this is a dangerous approach... so many other programs have had security issues in the past due to local websockets. Regarding the gRPC APIs themselves: When Another option might be for Mutagen to add a "plumbing" interface like Git has to support API access through invoking commands, but that's probably several months away at least. |
Would you consider adding an API to mutagen daemon ? Maybe with Websocket support to get notifications from the daemon ?
My idea is to build a web UI on top of this API to display synchronisation session informations, create/terminate/pause sessions, configure ignore list, and so on.
Using the command line to start/stop sessions is not that easy when you are running multiple synchronisation sessions.
The text was updated successfully, but these errors were encountered: