chi's ClientIPFrom* header middlewares trust the header from anyone who can
reach us. Pick the middleware per request instead: headers are only read
when the peer is a trusted proxy, everyone else gets their network address.
- PROXY_TRUSTED_PROXIES, defaults to loopback and private ranges
- PROXY_CLIENT_IP_HEADER, defaults to X-Forwarded-For, e.g. CF-Connecting-IP
- drop the strategy setting and xff_trusted_hops
- pass the client address to the services in X-Forwarded-For instead of
X-Client-Ip, reva reads it e.g. for OCM
- same check in collaboration, traefik routes to it directly
- OC_TRUSTED_PROXIES and OC_CLIENT_IP_HEADER set both services
- the other services only drop RealIP, none of them reads the address
Taken from #3864 and https://github.com/opencloud-eu/opencloud/pull/3464#issuecomment-6494799883
# Conflicts:
# services/proxy/README.md
When the tenant id coming in via the OIDC claims doesn't match the
tenant id on the provisioned user, a mapping can be configured and
resolved via the reva TenantAPI service (now started as part of the
"users" service).
Closes: #2310
When multi-tenancy is enable we now allow to specify an OIDC claim
against which the tenantid of the user resolved via CS3 apis is matched.
Partial: #2310
This is required for allowing the web office to download images to
insert into documents.
The secret is generated by `opencloud init` and the server refuses
to start now without a secret being set. (Breaking Change)
Also the setting is now moved to the shared options as all involved
services need the same secret to work properly.
Related: https://github.com/opencloud-eu/web/issues/704
* fix: collaboration service name
* change: do not use app name in service name
* feat: make collaboration service name configurable
* test: fix test config
With the ocdav service being able to provided signed download URLs we
need the proxy to be able to verify the signatures.
This should also be a first step towards phasing out the weird ocs based
client side signed urls.
Related Tickets: #1104
This introduces the "additional_headers", "remote_user_header" and
"skip_x_access_token" config keys to allow configuring routes to
external services that require addtional headers to be set.
"remote_user_header": defines the name of a Header that will carry the
userid of the authenticated user on the outgoing request.
"additional_headers": defines a list of header names and values that will
be added to outgoing requests on matching routes.
"skip_x_access_token": when set to true the reva access token will not
be added to the outgoing request.
Needed for #206
micbar