When following redirects, ensure that the final URL is not in the
configured DenyHosts list, but do not further enforce presence in the
AllowHosts list.
This was initially added in #237, and the original use case was about
protecting against redirects being used to bypass denied hosts. They
were using URL signatures and deny lists (for localhost, etc), but not
allow lists. So really, checking against the deny list is all that was
needed in that case.
This came up recently for me as I was trying to proxy images on a remote
host that redirects to Amazon S3. Even though the original URL was
signed, the redirect was being denied because s3-us-west-2.amazonaws.com
isn't on of my allowed host. But I don't want to allow all of S3, just
the signed URLs.
Add `MaxRedirects` option to set maximum redirection-followings allowed.
The option is only valid when `FollowRedirects` is `true`.
Being able to limit the amount of redirections is helpful in order to
avoid possible loops of redirections or just too long round trips.
Previously, when no keys were specified, copyHeaders would copy all
headers from src to dst. I believe this is a remnant of some old code,
as we don't actually ever use that behavior today.
I'm removing this as it seems too likely to accidentally pass along
headers that shouldn't be. Instead, let's always be explicit about
which headers to copy (which is what we currently do anyway).
Add a new passRequestHeaders field to Proxy that identifies headers to
pass from inbound request to remote servers. Also add associated flag
to imageproxy CLI.
This is initially added to support remote servers that require an
authorization token.
Fixes#321
- switch to "project authors" style copyright. Instead of an AUTHORS
file (https://opensource.google/docs/releasing/authors/), I just list
Google as a major copyright holder in the README.
- use SPDX style license headers in source files
- remove CLA requirement from contributing docs
this is an optional feature which is disabled by default, since it is
only needed in a few select cases and risks accidentally exposing
internal URLs.
Fixes#216
Some misconfigured servers will fail to properly set the content-type in
the response header. In those cases, detect the content-type from the
response body.
Refs #132
If the imageproxy instance is configured to only accept certain content
types (which defaults to "image/*"), set that as the accept header on
outbound requests.
Also log more information about the outbound request when the `Verbose`
option is set, so the request headers can be seen in the logs.
Fixes#165
Refs #132
the specific denial error message reveals more about the imageproxy
configuration than it should, such as what hosts are denied. Instead,
log the full error, but return a generic message that the requested URL
is not allowed.
This is what I probably should have called this when I renamed it back
in 70276f36, since this makes it more obvious that it's a list of
allowed hosts. Renaming now to make room for a `DenyHosts` variable as
part of #85.
If no content types are specified, then accept all responses, regardless
of content type (this is the behavior imageproxy has historically had).
Change default value for the contentTypes flag to be "image/*", so that
the new default when running cmd/imageproxy is that only images will be
proxied. The old default behavior can be achieved by passing an empty
string for the contentTypes flag:
imageproxy -contentTypes ""
Do not send the "XCTO: nosniff" header, since all documentation that I
can find still says that it can cause problems when served with images.
If it's effectively a noop when an explicit content-type is specified in
the response, then this shouldn't actually matter for us either way.
But in the absence of certainty, I'd rather err on the side of following
the spec.
Also add documentation for the new functionality.
Fixes#141
This has come up a couple of times, such as in #95. As discussed there,
I'm not completely sure this is actually necessary in many cases, but
it's certainly not harmful and if it makes health checks easier to setup
than why not?