Vaadin Push endpoint origin validation configuration for multi‑tenant deployments

Answer

Vaadin does not provide a built‑in per‑session origin whitelist for Push WebSocket connections. The framework relies on the browser same‑origin check and validates the TLS certificate against the server hostname only.

Confirmed facts

• Vaadin Push (including PushServlet) offers no public API to inspect the Origin header during the WebSocket handshake.
• In Vaadin 7‑8 a global setAllowedOrigins method existed on PushServlet, but it applies to all sessions and was deprecated/removed in later versions.
• Binding the Push endpoint to a specific network interface or IP address is a container/server configuration (e.g., server.address in Spring Boot, Tomcat Connector bindAddress, Jetty host), not a Vaadin setting.
• Multiple DNS names that resolve to the same IP will share the same Push endpoint; Vaadin cannot differentiate them at the framework level.

Likely explanation / recommended steps

1. Determine your Vaadin version. If you are on Vaadin 7 or 8 you can use the deprecated global setAllowedOrigins via a servlet init parameter or by extending PushServlet; this will allow a static list of origins but not per‑session.
2. For Vaadin ≥ 10 (Flow) there is no supported way to add a custom WebSocket handshake interceptor inside Vaadin. You must configure the underlying servlet container:
   • Tomcat: add a javax.websocket.server.ServerEndpointConfig.Configurator or a Filter that checks the Origin header and calls HttpServletResponse#sendError(403) before the handshake completes.
   • Jetty: implement a WebSocketHandler or use a Handler that inspects the request.
   Such container‑level checks cannot tie the decision to a specific Vaadin UI session because the handshake occurs before Vaadin creates the UI instance.
3. If you need per‑session origin whitelisting, deploy a reverse proxy (nginx, Traefik, Envoy) in front of the Vaadin instance and let the proxy validate the Origin header against a per‑tenant map, returning 403 for disallowed origins. The proxy must forward the original Origin header unchanged.
4. Alternatively, run a separate Vaadin Push server (or separate Vaadin instance) per tenant behind the proxy; each instance binds to its own IP/port or uses a distinct context path, allowing the proxy to route based on hostname.
5. To limit exposure by IP, configure the underlying HTTP server to listen only on the desired interface (e.g., server.address=10.0.0.5 in Spring Boot) and ensure all tenant DNS names resolve to that address. This does not provide origin isolation but reduces the attack surface.

Missing diagnostic detail

To decide whether the deprecated global setAllowedOrigins can satisfy your needs, please confirm the exact Vaadin version you are running.