I'm using the transmission daemon from the FreeBSD ports tree (it's version 2.13), and installing it also pulls in the web interface as a dependency. The problem, for me, is that there doesn't seem to be any way to disable the web interface without also disabling the RPC interface as well.
Does anyone know of a good way to do this? Also, does the above-mentioned dependency look like a distro-specific issue to you guys, or does that dependency exist upstream as well? How tightly integrated are the daemon and the web interface?
Thanks a lot!
Disable web UI but keep RPC interface
Re: Disable web UI but keep RPC interface
i've looked at the ./configure options from the nightly tarballs here and never saw a "--disable-webgui" option or similar, so i'm guessing it's tightly interwoven with the daemon.brianmwaters wrote:Also, does the above-mentioned dependency look like a distro-specific issue to you guys, or does that dependency exist upstream as well? How tightly integrated are the daemon and the web interface?
Well this might be an ugly hack, but you could remove (or better yet rename in case you want to restore it back) the index.html file:brianmwaters wrote:Does anyone know of a good way to do this?
Code: Select all
rename
/usr/local/share/transmission/web/index.html
to
/usr/local/share/transmission/web/index.html.disable
Also , if it exists in your user directory, do same for:
~/.local/share/transmission/web/index.html
-
- Posts: 2
- Joined: Wed Feb 02, 2011 11:44 pm
Re: Disable web UI but keep RPC interface
Really superficial inspection seems to suggest that the RPC interface actually uses CGI (like a RESTful API does) to talk to clients, and that the web interface actually has no server-side code like PHP or anything.
That would mean that the web interface is really just an HTTP server (which the RPC interface is using anyway) and a handful of static web content (HTML, CSS and JavaScript). So disabling the web interface would probably just mean removing the static content and disabling a few paths in the HTTP server, like for "example.com:9091/" and "example.com:9091/index.html". So it doesn't seem like it really even adds much extra code, or any additional ways to remotely (or insecurely) access the daemon - I guess they managed to tack the web interface on in a very intelligent way.
That being said, that whole insight comes from about 30 seconds of looking at it... But if that's right then it seems like a very good design, assuming the daemon isn't vulnerable to injection or overflow through the CGI params.
However, if the daemon does indeed work like I described, you could make it more secure by whitelisting RPC connections to localhost only, and then running a separate web interface under apache (or any other web server) on the same machine; that web interface could use something better than HTTP "basic" and plaintext session tokens for authentication.
EDIT: For the record, I just had a look at the RPC docs, and then watched the web interface in Firebug for a minute, and yeah, that is exactly how it works (except that requests put JSON in the POST body instead of passing regular CGI params). Cool. Do you think they would accept a patch for a "--disable-web-ui" configure option?
That would mean that the web interface is really just an HTTP server (which the RPC interface is using anyway) and a handful of static web content (HTML, CSS and JavaScript). So disabling the web interface would probably just mean removing the static content and disabling a few paths in the HTTP server, like for "example.com:9091/" and "example.com:9091/index.html". So it doesn't seem like it really even adds much extra code, or any additional ways to remotely (or insecurely) access the daemon - I guess they managed to tack the web interface on in a very intelligent way.
That being said, that whole insight comes from about 30 seconds of looking at it... But if that's right then it seems like a very good design, assuming the daemon isn't vulnerable to injection or overflow through the CGI params.
However, if the daemon does indeed work like I described, you could make it more secure by whitelisting RPC connections to localhost only, and then running a separate web interface under apache (or any other web server) on the same machine; that web interface could use something better than HTTP "basic" and plaintext session tokens for authentication.
EDIT: For the record, I just had a look at the RPC docs, and then watched the web interface in Firebug for a minute, and yeah, that is exactly how it works (except that requests put JSON in the POST body instead of passing regular CGI params). Cool. Do you think they would accept a patch for a "--disable-web-ui" configure option?
Re: Disable web UI but keep RPC interface
I would also be interested in this enhancement request.
Re: Disable web UI but keep RPC interface
The same web server that responds to RPC commands also serves the html/jpg/js/css files for the web server.
There's no mechanism to disable the web server from inside Transmission, but it should be pretty straightforward to disable by either
(1) setting your TRANSMISSION_WEB_HOME environment variable to /dev/null before starting Transmsision, or
(2) removing the web client's html/jpg/js/css files from your hard drive and stubbing in an empty index.html.
I probably wouldn't accept a "--disable-web-ui" patch unless there was a compelling use case. Most distro packagers break Transmission up into several different packages anyway.
There's no mechanism to disable the web server from inside Transmission, but it should be pretty straightforward to disable by either
(1) setting your TRANSMISSION_WEB_HOME environment variable to /dev/null before starting Transmsision, or
(2) removing the web client's html/jpg/js/css files from your hard drive and stubbing in an empty index.html.
I probably wouldn't accept a "--disable-web-ui" patch unless there was a compelling use case. Most distro packagers break Transmission up into several different packages anyway.
Re: Disable web UI but keep RPC interface
Hello,
I know this post is pretty old, but it's the only information I found about removing WebUI.
However, in 2014, is it still the way we should do it ?
Furthermore, with the rpc still activated and by using a tool such as Transmission remote GUI, are the passwords sent in plain text ?
I know this post is pretty old, but it's the only information I found about removing WebUI.
I followed option 2 and removed the files, it's still asking me the password but leads me to a blank page. (my empty index.html).Jordan wrote: (1) setting your TRANSMISSION_WEB_HOME environment variable to /dev/null before starting Transmsision, or
(2) removing the web client's html/jpg/js/css files from your hard drive and stubbing in an empty index.html.
However, in 2014, is it still the way we should do it ?
Furthermore, with the rpc still activated and by using a tool such as Transmission remote GUI, are the passwords sent in plain text ?