Cannot run two applications on localhost (with different ports) in same browser

[jflamy]

Description of the bug

If I run two Vaadin applications on (say) localhost:8080 and localhost:8081 I cannot access them from the same browser - the UIs start updating randomly until one of the two is closed.

It is necessary to either use two different browsers, or to fake the addresses to 127.0.0.1:8080 and 127.0.0.2:8081

Expected behavior

Two URLs have the same origin if the protocol, port (if specified), and host are the same for both.

Since the applications are from different origins, they should be considered different

Minimal reproducible example

Run any two Vaadin applications simultaneously on localhost:8080 and localhost:8081, access them from the same browser.

(may or may not be relevant: Both applications have @Push enabled.)

Versions

Vaadin: 24.1.9
Flow: 24.1.11
Java: JetBrains s.r.o. 17.0.6
OS: amd64 Windows 11 10.0
Browser: Chrome Edge Firefox
Live reload: Java active (HotswapAgent): Front end active

[mcollovati]

If the host is the same, the applications should have different cookie names.

Here are a couple of excerpts from the RFC 6265

Introduction

cookies for a given host are shared across all the ports on that host, even though the usual "same-origin policy" used by web browsers isolates content retrieved via different ports.

Security Considerations > Weak Confidentiality

Cookies do not provide isolation by port. If a cookie is readable by a service running on one port, the cookie is also readable by a service running on another port of the same server. If a cookie is writable by a service on one port, the cookie is also writable by a service running on another port of the same server. For this reason, servers SHOULD NOT both run mutually distrusting services on different ports of the same host and use cookies to store security-sensitive information.

In a Spring Boot application the cookie name can be with the server.servlet.session.cookie.name property

[jflamy-dev]

I am not using Spring Boot, just running off an embedded Jetty.
I do not use my own cookies.
There seems to be a generic ServletContext.getSessionCookieConfig()
that has a setName() method.
Is that what I should be invoking, and if so, what would be the correct location to do this early enough in the Vaadin initialization?

[mcollovati]

I suppose a ServletContextListener could be a good point to set the session cookie name.
Probably jetty also provides some context parameter or other way to set it.

[jflamy]

There is a generic Servlet API call.
The following two lines in my embedded jetty startup solved the issue.
The generic way to get the app context would work, I did not look it up.

		final WebAppContext context = createWebAppContext();
		context.getSessionHandler().setSessionCookie("V"+System.currentTimeMillis());

Is there a reason that Vaadin can't set the cookie name to some random junk and avoid this forever ?

[mshabarov]

At least this is something we have to describe in the online documentation.
Not sure we have to include pre-configured session cookie by default, because this depends on app deployment and Servlet API provides methods for setting it up.

[Legioth]

Is there a reason that Vaadin can't set the cookie name to some random junk and avoid this forever ?

Vaadin has no way of preserving that random junk over server restarts and we wouldn't want to cause hundreds or thousands of different cookie names to end up the the developer's browser.

[jflamy]

Thanks. I was just observing junk accumulation myself.
Documenting the behaviour would be nice though.

[mshabarov]

Documentation has been updated.