Summary
SecureSendController builds the share URL from the servlet context path plus the internal API path:
ServletUriComponentsBuilder.fromCurrentContextPath()
.path("/api/public/secure-sends/{token}")
This assumes that the service is reachable under /api on the public host. In the current deployment that assumption is wrong. The reverse proxy maps this backend to /cloud-api/, while /api/ belongs to the vault-web core backend. The link handed to the user therefore points at a completely different service.
How to reproduce
Create a secure send and open the returned link, for example:
https://vault.deniz-dev.com/api/public/secure-sends/<token>
Result:
{"code":"UNAUTHORIZED","message":"Unauthorized","timestamp":"..."}
That response body is produced by the vault-web core backend, not by cloud-page.
Evidence
The core backend logs the request when the link is opened:
WARN v.security.JwtAuthenticationEntryPoint : Unauthorized request to GET /api/public/secure-sends/<token>
The externally reachable path for this service is /cloud-api/public/secure-sends/, since the proxy maps /cloud-api/ to this backend at /api/.
Expected behaviour
The link returned by the create endpoint is the link that actually works for a recipient in the given deployment.
Suggested fix
Make the public base URL configurable instead of deriving it from the internal servlet path, for example a property such as cloudpage.secure-send.public-base-url that defaults to the current behaviour when unset. The controller then appends only the token segment to that base.
Configuring server.forward-headers-strategy alone does not help here, because the wrong part is the path prefix, not the host or the scheme.
Related
Even under the correct path the endpoint currently returns 403, because the JWT filter rejects anonymous requests. Both problems need to be fixed for share links to work.
Summary
SecureSendController builds the share URL from the servlet context path plus the internal API path:
This assumes that the service is reachable under /api on the public host. In the current deployment that assumption is wrong. The reverse proxy maps this backend to /cloud-api/, while /api/ belongs to the vault-web core backend. The link handed to the user therefore points at a completely different service.
How to reproduce
Create a secure send and open the returned link, for example:
Result:
That response body is produced by the vault-web core backend, not by cloud-page.
Evidence
The core backend logs the request when the link is opened:
The externally reachable path for this service is /cloud-api/public/secure-sends/, since the proxy maps /cloud-api/ to this backend at /api/.
Expected behaviour
The link returned by the create endpoint is the link that actually works for a recipient in the given deployment.
Suggested fix
Make the public base URL configurable instead of deriving it from the internal servlet path, for example a property such as cloudpage.secure-send.public-base-url that defaults to the current behaviour when unset. The controller then appends only the token segment to that base.
Configuring server.forward-headers-strategy alone does not help here, because the wrong part is the path prefix, not the host or the scheme.
Related
Even under the correct path the endpoint currently returns 403, because the JWT filter rejects anonymous requests. Both problems need to be fixed for share links to work.