Now if you reach server from external and the server has local IP on red interface you’ll be redirect to https://hostname:980
If you reach it from Internet, but server has got public IP on red interface or you are in the same network of the server you’ll be redirect to https://InterfaceIP:980.
If someone wants to test it the command is: yum install http://packages.nethserver.org/nethserver/7.6.1810/autobuild/x86_64/Packages/nethserver-httpd-admin-2.3.4-1.2.pr34.g84c459d.ns7.noarch.rpm
Why? Why would you ever want to redirect to https on an IP address, virtually guaranteeing a certificate error? And how does your change result in the server speaking both HTTP and HTTPS on port 980?
I’m trying to improve the redirect when you call http://servername:980 but the server hasn’t got a public IP on Red interface. With my PR if you have a private IP and you are calling server manager from Internet you’ll be redirect to https://servername:980
I understand what the patch does, but I can’t get in which cases it can be useful.
If you don’t have a public IP, probably neither of both redirects will work.
As maintainer, I see 30 new lines code which will work on very few cases.
Maybe I’m wrong, it seems that @robb appreciate the changes.
Does anyone else find this feature useful? What are the use cases?
@danb35 i’m modifying the error 400 bad request apache page.
@giacomo if Nethserver si behind a router your red IP will probably be 192.168.x.x:980 for example. As now, you will redirect to https://192.168.x.x:980 that is surely not reachable form Internet. With my patch you will be redirect to https://servername:980 that probably is reachable form Internet.
It doesn’t work only in the case that red Ip is private and there isn’t any DNS pointing to server name.
…probably! As we cannot find the perfect solution I propose a simpler implementation.
…Replace $url on line 15 with a new $_SERVER['SERVER_NAME'] based URL (say $url2). So if the META http-equiv does not work the suggested URL could work as manual fallback.
I wonder if the SERVER_NAME can be subject to DNS attacks though… For instance SERVER_NAME value is server.lan and a poisoned DNS reply sends me to a malicious server.lan IP… Please do not consider it.
But if you are on LAN and working on a server that have “domain.lan” hostname and you haven’t got DNS set properly, you’ll not able to reach the server.
My PR, doesn’t work only in the case that red Ip is private and there isn’t any DNS pointing to server name and you are calling the server from outside (but it doesn’t work also now…)
This is tipically the case in a double NAT situation where your Router NAT’s to a private subnet and in that subnet your NethServer RED interface is part of that private subnet. NethServer NAT’s to another private subnet where your GREEN interface is default gateway for the rest of your LAN.
I have this situation at home and it has been working like a charm for years. The only thing you need to be aware of that you can not have any clients on the subnet of your RED interface. This also means that if the router you use (probably obtained from your ISP) has an Accesspoint, you have to disable that accesspoint and add another Accesspoint on your LAN (GREEN subnet).