Before, if a site's certificate was not found, the site was served
over http rather than https. Failing open like this is problematic
for sites where security is important. Presumably the user set
`HTTPS_METHOD` to a non-`noredirect` value (or left it unset) for a
good reason; we should honor it even if it means serving error
messages.
WARNING: This change breaks compatibility. Any vhost where all of the
following are true will fail after this change:
* `HTTPS_METHOD` is either unset or set to a value other than
`nohttps`.
* The vhost does not have its own certificate (`default.crt` doesn't
count).
* Clients expect to be able to access the vhost by using plain http
to nginx-proxy.
To get the previous behavior, set `HTTPS_METHOD` to `nohttps` for the
vhost.
Before, a fallback http server was created to handle requests for
unknown virtual hosts even when `HTTPS_METHOD=nohttp`. (In this case,
all http vhosts would be unknown.) Likewise, a catch-all fallback
https server was still created even if `HTTPS_METHOD=nohttps`.
Now the fallback servers are created only if needed. This brings the
behavior in line with the documentation and user expectation. It will
also make it easier to implement a planned feature: different servers
on different ports.
Before, if neither the vhost-specific cert nor `default.crt` existed,
nginx-proxy would not create the https vhost. This resulted in nginx
either refusing the connection or serving the wrong vhost depending on
whether there was another https vhost with a certificate.
Now nginx-proxy always creates an https server for a vhost, even if
the vhost-specific certificate and the default certificate are both
missing. When both certs are missing, nginx is given empty
certificate data to make it possible for it to start up without an
error. The empty certificate data causes the user to see a TLS error,
which is much easier to troubleshoot than a connection refused error
or serving the wrong vhost.
Add initial tests
Newlines
Remove unused variable
Co-authored-by: Richard Hansen <rhansen@rhansen.org>
Change comment value
Co-authored-by: Richard Hansen <rhansen@rhansen.org>
add missing services line
Co-authored-by: Richard Hansen <rhansen@rhansen.org>
Use deploy.replicas
Remove details about choosing a load balancing method
Feedback note
Co-authored-by: Nicolas Duchon <nicolas.duchon@gmail.com>
This partially reverts commit 2494e20784
by ignoring any network named "ingress" when searching for a
container's IP address.
That commit was technically a backwards-incompatible change: Some
users use nginx-proxy with Swarm mode even though it is not fully
supported. In such cases nginx-proxy should ignore the `ingress`
network, otherwise nginx will not be able to reach the
server (container-to-container traffic apparently doesn't work over
the Swarm `ingress` network).
The parts of that commit that examine the `SwarmNode` structure are
not reverted here because docker-gen does not currently populate that
structure -- not even when both docker-gen and the service task
container are running on the same manager node.
In particular, reduce the nesting depth to make it easier to
understand what the code is doing by:
* converting an $O(nm)$ nested loop into two serial $O(n)+O(m)$
loops, and
* consolidating similar nested `if` cases.
to ensure that the version is always the first output line.
Also, always output `# nginx-proxy`, even if the version isn't known.
This makes it easier to find the start of the generated config in the
output of `nginx -T`.
Rationale for eliminating the check to see if the `DEBUG` environment
variable holds a true value:
* The `DEBUG` environment variable might be set on a container (for
purposes specific to that container, not `nginx-proxy`) to a value
that cannot be parsed as a bool, which would break `nginx-proxy`.
* It simplifies the template.
* It eliminates a cold code path.
* It avoids heisenbugs.
* It makes debugging easier for users.
Also delete the debug info tests, as they are fragile and they provide
limited value.
Alternatively, we could avoid collision with the container's use of
the `DEBUG` environment variable by using a container label [1] such
as `com.google.nginx-proxy.nginx-proxy.debug`. I think doing so has
dubious value, especially if we want to attempt backwards
compatibility with the `DEBUG` environment variable.
Fixes #2139
[1] https://docs.docker.com/engine/reference/commandline/run/#-set-metadata-on-container--l---label---label-file
Co-authored-by: Nicolas Duchon <nicolas.duchon@gmail.com>
If header values from a malicious client are passed to the backend
server unchecked and unchanged, the client may be able to subvert
security checks done by the backend server.
This features allows the custom location blocks to be added to the
virtual path based routing. The custom config can be specified for each
container individually.
This commit removes the automatic path stripping and replaces it with a
user configurable environment variable. This can be set individually for
each container.
Richard Hansen
Nicolas Duchon
Niek
Jan Malte Gerth
Vincent Herlemont
浊酒
SilverFire - Dmitry Naumenko
Nitin Jain
Alexander Lieret