List port non webserver-based ports in the panel and make every web based app SSL based


#1

Topic says it all.

I blow my box away on a regular basis and I never write down my deluged port info so I’m having to look it up every time.

I notice that the apps are not SSL enabled. Given the push to make everything SSL enabled, I think you should make all apps SSL enabled by default.


#2

This would require a great deal of forwarding to be done in the apache configuration. It is something that I have indeed put a tremendous amount of thought towards, however, some applications are independent of the process that you or I would prefer. Some applications can have SSL enabled from their own internal settings and some are not SSL enabled by how they deliver on ports other than 443.

I will look into this, however, this is something that we would need a great many of these applications very own authors to address… not QuickBox. This statement does not rule out however the ability to forward ports, and it is something that I have in the roadmap… however, there is no eta on this process.

Now, in regards to displaying port info etc … I think this would be a nice feature to display (maybe under the user dropdown even :slight_smile:) on the dashboard.


#3

Just spitballing ideas, but what about a 2nd apache process acting as an SSL proxy, acting as an ssl tunnel / gate-keeper of sorts to the non-SSL enabled apps behind it?

edit - or for that matter, nginx or lighttpd instead of apache?


#4

Nginx is actually part of the plan in future versions and I have had it in closed development for about a month now. It’s a pretty big undertaking to have all these processes (especially for multi-user installs) to work nicely on nginx. I am 100% certain that using nginx would additionally make the forwarding a much simpler process.

The problem with SSL proxy is when it comes down to multi-users, I have hit a few hurdles in the process that I need to overcome first. I wish it were as simple as something working that should just work. :blush:


#5

I dont think you need even another apache. I had Swizards provision a private box of mine. I then customized it as I needed to.

I just added a 2nd config file in apache2/sites-available and sites-enabled like this:

/etc/apache2/sites-enabled$ more proxy.conf
<Location /movies/>
ProxyPass http://localhost:5050/movies/
ProxyPassReverse http://localhost:5050/movies/

     <Location /tv/>
            ProxyPass http://localhost:8989/tv/
            ProxyPassReverse http://localhost:8989/tv/
    </Location>

     <Location /jackett/>
            ProxyPass http://localhost:9117/
            ProxyPassReverse http://localhost:9117/
    </Location>

then I could go to https://host_name/tv/ and it would get Sonarr.
The catch was I needed to put in the last / at the end otherwise I get Swizards code errors.


#6

Noted I’ll run this through some tests as soon as I have time. I had previously done the same thing to have a public facing Plex. In theory, it should work and be the exact same process… it’s just a matter of adjusting all the install functions and have the packages perform these needed touches on apache… then to remove them when uninstalled.


#7

a bit ugly but https://server_name/user_sonarr/ for user’s sonarr.

you could go another level deeper like https://server_name/user/sonarr/ which might not be a bad idea. I’ve never setup a reverse proxy 2 levels deep though so I dont know how thatd look.


#8

This works fairly decent for Plex:

RewriteRule ^/plex/?$	/plex/web/index.html	[R=301]
<location /plex/>
	ProxyPass			http://127.0.0.1:32400/web/
	ProxyPassReverse		http://127.0.0.1:32400/web/
	ProxyPassReverseCookiePath 	/		/plex/
	ProxyPassReverseCookieDomain	127.0.0.1	192.168.1.110 <-- replace with your server ip
</location>

I am hitting a caveat with Deluge however… still working that one out. It is only producing a blank screen.