Authentication for a HTTP only WebUI - Transmission behind Nginx Proxy

[j-archit]

Note: I do not understand js and so have not tried going over the source.

Do correct me if I'm wrong, but as I understand the extension, the WebUI authentication should be working directly over the port specified and use http(s) as per the bt client's configuration. If that is the case, a client such as Transmission (doesn't support https) must be exposing the WebUI authentication information.

Is there a way to circumvent this, for example directing the authentication via a reverse proxy setup (nginx, caddy?) or should the authentication be dropped altogether?

[bogenpirat]

If that is the case, a client such as Transmission (doesn't support https) must be exposing the WebUI authentication information.

This is true in the sense that any authentication over http is susceptible to mitm-attacks that may just record your credentials.

The way to circumvent that would be to use a reverse proxy that serves the web ui over tls, yes. That would shield the login from mitm-attacks. I don't understand why disabling authentication would be an option.

[j-archit]

The way to circumvent that would be to use a reverse proxy that serves the web ui over tls, yes. That would shield the login from mitm-attacks. I don't understand why disabling authentication would be an option.

So I am indeed using nginx to reverse proxy to transmission, I am trying to block off all ports (save a select couple of ports, eg 80, 443) to all external communication except from localhost. Now the issue is the extension is not able to add the torrents if I close the rpc port, is there a way to make the extension work with a reverse proxy?

Leaving the rpc port enabled allows for mitm attacks as transmission is http only, but yes on second thoughts, disabling auth is not really an option.

[bogenpirat]

Now the issue is the extension is not able to add the torrents if I close the rpc port, is there a way to make the extension work with a reverse proxy?

i frankly don't know. i've not reverse-proxied to transmission myself. all i can say is: if you can add torrents manually via transmission's web UI in a reverse-proxied environment, RTA should be able to do it as well. so your goal should probably be to achieve that without RTA in the equation - one less moving part.

in any case, this doesn't strike me as an RTA problem specifically. let me know if i'm misjudging this and i'll reopen the issue.

[j-archit]

if you can add torrents manually via transmission's web UI in a reverse-proxied environment

I can. The client works perfectly with the reverse proxy.

in any case, this doesn't strike me as an RTA problem specifically.

Do correct me this is not how it works, but the extension sends a request direct to the WebUI port, right? It won't work if that very port was blocked by the firewall.

The reverse proxy setup uses the http(s) ports only, so only those are available. While accessing transmission, all requests are handled by nginx which are then forwarded via the loopback interface to the WebUI port (which can ONLY be accessed via the loopback interface).

The extension will have to work around this. So I do think it is an extension problem. Although I'd say this can be a feature enhancement as many clients do not support https out of the box.

[bogenpirat]

RTA will treat any ip/port you specify as the torrent client's web ui. if you're reverse-proxying the torrent client's web-ui-http-port to some SSL/TLS-capable https port that you can use in a browser window to manually add a torrent given your credentials, then RTA should be able to do the exact same thing since it essentially just automates that sequence of requests - login and torrent upload.

in a very basic sense, refer to this line in the code that constructs the URL for api requests:

const apiUrl = "http" + (server.hostsecure ? "s" : "") + "://" + server.host + ":" + server.port + "/transmission/rpc";

as you can see, this does nothing other than append protocol (http/s), server host, port and the client-specific api path. it does respect the protocol (SSL) choice from the settings dialog as well as the given port (usually 443 for standard ssl setups, but freely selectable).

from what you're explaining, i get the sense that you think that the web ui (html/js/css) that transmission hosts is on a separate port from the RPC interface? this has not been the case for any of my experiences with this client software. given that they are served by the transmission software on the same port - be that bound to loopback and then reverse-proxied by nginx to an externally accessible interface - you should be able to just direct RTA to that nginx https host/port and it should work as expected.

let me know if i still misunderstand what your setup is.

[j-archit]

You did get it right. I've set a custom port for the Transmission RPC/WebUI port, and nginx reverse proxies to that port via loopback.

I tried setting the nginx https port as the WebUI port, however RTA is still not able to add the torrent to the WebUI. Do you have any ideas as to why that is? Any logs I can paste here?

[bogenpirat]

Any logs I can paste here?

sure! go to chrome://extensions/?id=oabphaconndgibllomdcjbfdghcmenci, enable developer mode in the top right, then under inspect views click on background page and go to the console tab. with that open, try to add a torrent. there's gonna be an error message if it fails. for more details, the network tab will have a failed request you can click on that'll reveal why it failed.

[j-archit]

Alright, so I did that and got this:

POST https://<hostname/ip>/transmission/rpc 405 (Method Not Allowed) 

RTA.clients.transmissionAdder | @ | TransmissionWebUI.js:4
  | RTA.dispatchTorrent | @ | functions.js:20
  | RTA.getTorrent | @ | functions.js:65
  | (anonymous) | @ | background.js:76

Some quick research explains that this is an nginx limitation. I tried some solutions mentioned on this stackoverflow question, that also led to one on this blog. But got the same error. Looks like I'm gonna have to make a sacrifice in terms of an open port or resorting to manually adding the torrents now.

I'd recommend leaving this thread somewhere for anyone else encountering this issue.

[bogenpirat]

aight, thanks for the followup. have you tried something like this? it seems odd that a reverse-proxied application cannot receive POST requests. i'm basically certain that this works with apache reverse proxying.

[j-archit]

have you tried something like this

I am using this. So unless I am doing something incorrectly or missing something (I'm relatively new to nginx), it still doesn't work, I still get the 405. Here is the relevant nginx config, let me know if I'm missing something,.

        ############ Transmission ############
        location ^~ /transmission {
                return 301 http://$server_name/transmission/;
        }

        location ^~ /transmission/ {
                proxy_pass_header X-Transmission-Session-Id;

                proxy_read_timeout      60s;
                proxy_http_version      1.1;
                proxy_set_header        Host                    $host;
                proxy_set_header        X-Forwarded-Host        $host;
                proxy_set_header        X-Forwarded-Server      $host;
                proxy_set_header        X-Forwarded-For         $proxy_add_x_forwarded_for;
                proxy_set_header        X-Real-IP               $remote_addr;
                proxy_pass              http://localhost:<webui_port>/transmission/web/;
        }

        location ^~ /rpc {
                proxy_pass      http://localhost:<webui_port>/transmission/rpc;
        }