When an access list was associated with a template which had users (items) but no rules (clients), a `deny all` directive was inserted to the config. This resulted in all requests, including those with valid credentials, being rejected due to the lack of any `allow` directive.
This commit wraps the access rule configuration inside of an if block, so the `deny all;` directive is only present when at least one rule is configured.
When Nginx is behind another proxy server (like CloudFlare or AWS ALB), the force-SSL
feature can cause redirect loops because Nginx sees the connection as plain HTTP
while SSL is already handled upstream. This adds a new boolean option to trust
the X-Forwarded-Proto header from upstream proxies.
Changes:
- Add `trust_forwarded_proto` column to proxy_host table (migration)
- Update model and API schema to support the new boolean field
- Modify force-ssl Nginx template to check X-Forwarded-Proto/X-Forwarded-Scheme
- Add map directives in nginx.conf to validate and sanitize forwarded headers
- Add advanced option toggle in frontend UI with i18n support (EN/ZH)
- Set proxy headers from validated map variables instead of $scheme
This allows administrators to control SSL redirect behavior when Nginx is deployed
behind a TLS-terminating proxy.
Wrong logic to pass auth as header: when disabled (pass_auth=0) credentials are included in Authorization header. However as soon as you enable (pass_auth=1) they are not.
By using a static URL, the backend server can be accessed reliably, avoiding the common 404 errors or "no resolver defined" issues seen when variables are used.
I can only server contents with IPv6 because I'm sitting behind CGN on IPv4. When enabling HTTP2 it still not serve contents with HTTP2 as there are missing arguments in the `listen`. But it still does the SSL encryption.
Previous to this commit it generates:
```
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443;
```
Now it generates:
```
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
```
If a custom location is currently set to proxy to a DNS hostname this hostname is cached by nginx. When the underlying IP for the hostname changes this will be cached in nginx until it is restarted. This behaviour is somewhat undesirable if utilising containers.
This change sets the proxy_pass for custom locations into a variable and utilises said variable for routing to the upstream backend. This will ensure that nginx will utilise the resolver and resolve the hostname to the current IP instead of relying on the nginx cache.
Matthew Kilpatrick
jerry-yuan
Alex Kitsul
Eduard Paul
jbowring
Miguel Angel Nubla
mitossoft-rd
jc21
Chris Maffey
Sergey 'dreik' Kolesnik
Dhrumil Shah
clhey
David Indra
Jocelyn Le Sage
Dario Viva
Will Rouesnel
Tobias Kneidl
chaptergy
Julian Reinhardt
bergi9
Amir Zarrinkafsh
vipergts450
Björn Heinrichs
Daniel Porter
David Dosoudil
baruffaldi
Shuro