Public URL Configuration
The Public URL is what you expect users of this LiquidFiles system to use when interacting with this LiquidFiles system. In the most basic example, your domain is mycompany.com and you want to use LiquidFiles using: https://liquidfiles.mycompany.com.
The Public URL configuration in LiquidFiles is available in Admin → System → Hostname & Public URL and looks like:
1: Public URL
The Public URL is the externally facing Protocol and Public Hostname and is used for most thing in LiquidFiles like when sending email links and similar. Enter the URL you want your users to use when connecting to LiquidFiles.
2: System Hostname
The System Hostname is the Internal hostname of the system, which is used for things like naming backups and similar, it's not exposed externally. You can set this to the same as the Public Hostname if you want.
The Protocol Settings determines what happens when someone connects to the system using the non-preferred method, i.e. what should happen if someone connects using HTTP and you have selected the Public URL to be HTTPs. There's three settings:
|In this mode, all traffic is forced to use https. Connections on http will be instantly redirected to https. This is the default.
|All traffic is forced to use http. Connections on https will be instantly redirected to http.
|Permit either HTTP or HTTPs
|With this setting, LiquidFiles does not care if users use HTTP or HTTPs, this is a typical setting when using a Reverse Proxy with LiquidFiles.
4: Hostname in URLs
Looking at an example, when someone logs in to LiquidFiles, this is the HTTP methods and URLs that will be used:
302 Location: https://files.liquidftest.com/message/new
The first is when the browser connects to the home page of the LiquidFiles system. When the users enters their username, password and hits login, they will send a HTTP post to /login. If the authentication is successful, the browser will be redirected (HTTP 302) to the compose message page.
Without Enabling "Hostname in URLs", LiquidFiles will redirect the browser to the current hostname and protocol. When Enabling "Hostname in URls", LiquidFiles will redirect the browser to the Public Hostname regardless of the current hostname and protocol.
In some cases, like when using a HTTPs → HTTP reverse proxy setup, LiquidFiles only sees the HTTP hostname/protocol so it will redirect to http://.... which is not working properly. Enabling Hostname in URLs in those situations will make this setup work.
On the other hand, when Enabling "Hostname in URLs", this removes the ability to login using IP address for testing purposes.
5: Strict Public Hostname validation
When enabled, LiquidFiles will validate that the browser URL matches the Public Hostname. If it doesn't, it will redirect the browser to the Public Hostname.
Enabling Strict Public Hostname validation can increase security. Please be aware though that the Public Hostname is what's being used because this can cause redirect loops.
As an example, lets say that you're using a reverse proxy and the Public Hostname https://liquidfiles.company.com. The reverse proxy is set to connect to the LiquidFiles IP address: http://10.1.2.2. If Strict Hostname validation was enabled, LiquidFiles would detect the URL as http://10.1.2.2, see that it doesn't match https://liquidfiles.company.com, redirect the browser to https://liquidfiles.company.com, which the reverse proxy would connect to http://10.1.2.2, which doesn't match...
6: Trusted Proxies
If you use a Reverse Proxy, on default from LiquidFiles perspective, all connections are coming from the Reverse Proxy. If a user triggers the brute force protection — the reverse proxy (i.e. everyone) would be blocked. When performing a GeoIP lookup of the download, only the reverse proxy IP would be seen.
Reverse Proxies send a X-Forwarded-For header, with the IP address of the client that was forwarded to LiquidFiles (in our case). As this information could be used to bypass IP address restrictions and similar, we cannot simply trust that the X-Forwarded-For proxy is accurate. By entering the IP address of the reverse proxy/proxies here, it tells LiquidFiles that it can trust and use the X-Forwarded-For IP address instead of the reverse proxy IP address. Please make sure you use the inside IP address of the reverse proxy — the one that the LiquidFiles system sees.