June 23, 20179 yr Can we have a toggle switch or checkboxes for https support and redirect like was done with uefi support instead of having to edit go file? Sent from my iPad using Tapatalk
June 23, 20179 yr 3 hours ago, bonienl said: Here you go... Does the apply button reset nginx with the new config? If so, does the current session automatically get redirected to a valid url if the previously in use port is changed? Or, does the change take effect on the next reboot?
June 23, 20179 yr Current implementation is as follows: 1. Allow user to select GUI protocol: HTTP, HTTPS or REDIRECT 2. Allow user to select default or custom port(s) of selected protocol 3. Perform a validation to see if selected port(s) are free 4. If ports are free then update the go file and restart nginx + php-fm with the new settings It could be that the GUI becomes unreachable due to the changed settings. In that case the new URL needs to be entered. E.g. //tower becomes //tower:8080
June 23, 20179 yr 27 minutes ago, bonienl said: It could be that the GUI becomes unreachable due to the changed settings. In that case the new URL needs to be entered. E.g. //tower becomes //tower:8080 Since you have the appropriate setting saved at that point, could you not issue a browser command to open a new window or refresh the current window with the new information automatically?
June 23, 20179 yr 2 minutes ago, jonathanm said: Since you have the appropriate setting saved at that point, could you not issue a browser command to open a new window or refresh the current window with the new information automatically? AFAIK not possible. There is a catch 22 issue here. Once the new settings are submitted and nginx uses them, then it is not possible anymore to return and get control. There are things which work automatically and GUI stays accessible, as long as standard ports are used: 1. Change from HTTP to REDIRECT 2. Change from HTTPS to REDIRECT 3. Change from REDIRECT to HTTPS
June 23, 20179 yr 49 minutes ago, bonienl said: AFAIK not possible. There is a catch 22 issue here. Once the new settings are submitted and nginx uses them, then it is not possible anymore to return and get control. Interesting. I wonder how some consumer routers do it. When you change the IP of the router, it refreshes the page with a new page at the updated address. It looks possible with a tiny bit of javascript.
June 23, 20179 yr <!DOCTYPE html> <html> <head> <title>example</title> </head> <body> <p>You will be redirected to the WebGUI shortly.</p> <script> setTimeout(function(){ window.location.replace="http://<IP>:<Port>"; // The URL that will be redirected to. }, 3000); // The bigger the number the longer the delay. </script> </body> </html> I'm not a web coder, so I don't know how to insert the proper values into IP and Port.
June 23, 20179 yr For -rc6 I asked bonienl to remove this because the port specification/redirect on the command line of 'emhttp' in the 'go' file is a bit of a hack. https is really "experimental" at this point because we need to integrate with a method of dealing with certificates. It's not good enough to have a self-signed certificate in today's world where browsers produce huge scary warnings. For those of you who understand how to deal with https, it's not too much to ask, imho, to directly edit your 'go' file appropriately for now.
June 23, 20179 yr 20 minutes ago, limetech said: For -rc6 I asked bonienl to remove this because the port specification/redirect on the command line of 'emhttp' in the 'go' file is a bit of a hack. https is really "experimental" at this point because we need to integrate with a method of dealing with certificates. It's not good enough to have a self-signed certificate in today's world where browsers produce huge scary warnings. For those of you who understand how to deal with https, it's not too much to ask, imho, to directly edit your 'go' file appropriately for now. That's cool. I understand not wanting to deal with self signed certificates, or requiring people to set up a FQDN for their unraid box while simultaneously telling them they shouldn't forward the port to the internet. However... now that the daemon is separate from the nginx server, can we get the official commands to restart the GUI? Pretty please?
June 23, 20179 yr 3 minutes ago, jonathanm said: However... now that the daemon is separate from the nginx server, can we get the official commands to restart the GUI? Pretty please? NVM. I just reread the release notes for the current rc series, and it's apparent that restarting the GUI is still being worked out, since stopping it isn't supported with the array started. I can wait.
June 23, 20179 yr 14 minutes ago, jonathanm said: NVM. I just reread the release notes for the current rc series, and it's apparent that restarting the GUI is still being worked out, since stopping it isn't supported with the array started. I can wait. Yes that will be added before 'stable'.
June 25, 20179 yr what about just including a letsencrypt docker/plugin which auto renews/sets up the https for nginx (webui) ? https://github.com/linuxserver/docker-letsencrypt Edited June 25, 20179 yr by zoggy
June 25, 20179 yr 2 hours ago, zoggy said: what about just including a letsencrypt docker/plugin which auto renews/sets up the https for nginx (webui) ? https://github.com/linuxserver/docker-letsencrypt Sadly those services don't work with internal only facing servers. LT and crew have been making huge improvements on the security front, but I'm still not sure its ready to be internet facing. Edited June 25, 20179 yr by smdion
June 25, 20179 yr 1 hour ago, smdion said: Sadly those services don't work with internal only facing servers. LT and crew have been making huge improvements on the security front, but I'm still not sure its ready to be internet facing. well they seem to be against self signed certs.. which is why I mention it.
June 26, 20179 yr On 6/24/2017 at 8:13 PM, smdion said: Sadly those services don't work with internal only facing servers. LT and crew have been making huge improvements on the security front, but I'm still not sure its ready to be internet facing. Not sure about the docker version of LetsEncrypt, but there is no reason the server needs to be Internet facing for LetsEncrypt to work. I use the ACME plugin on my PFSense box that runs internally on my network just fine. It auto renews the certificate and installs it, even though the box is not Internet reachable. You just need to register an account key with the CA and use a renewal method like DNS-Manual. Note: this does require you to control a valid Internet DNS Domain name. I would love to see a pre-configured and packaged docker version of LetEncrypt be integrated into UnRaid UI. It could be used to automagically protect the admin UI and any other HTTPS docker on the system.
June 28, 20179 yr On 6/27/2017 at 0:39 AM, ssb201 said: automagically The DNS method for LetsEncrypt is far from an automatic magical process. You need to own the domain and add TXT records...
June 28, 20179 yr 14 minutes ago, sarbian said: The DNS method for LetsEncrypt is far from an automatic magical process. You need to own the domain and add TXT records... The magic is ongoing maintenance, not during setup.
Archived
This topic is now archived and is closed to further replies.