DevTools should change default session cookie name to be unique per port

[rwinch]

Problem

Session cookies are scoped by host and path only, not by port. Running multiple apps on localhost on different ports (e.g. 8080 and 8081) shares the same cookies, so one app’s session cookie can override the other’s (e.g. logging into one app logs you out of another).

Workarounds and drawbacks

There are a few workarounds that can be used:

• Developers can use different hosts (127.0.0.1, localhost, 192.168.x.x). The problem with this is that you have to remember host and port per app. Beyond a couple of apps it gets fragile without editing the hosts file.
• Unique session cookie name (e.g. SESSION_${server.port}). This works well, but requires explicit configuration that should not be required.

Proposed solution

When DevTools is on the classpath, automatically make the default session cookie name unique in development (e.g. suffix with server port, like SESSION_8081), so multiple apps on localhost with different ports don’t overwrite each other’s session.

[philwebb]

I'm not totally convinced about making devtools the driver for this as I worry that folks don't notice these kinds of subtle changes and then become confused when something works in their IDE but not when doing java -jar.

I wonder if we should instead try to encourage the use of spring.application.name and always apply that the the session cookie?

I'll flag the issue for further discussion.

[wilkinsona]

Doing anything to the session cookie name feels a little too magical to me. If you're working on an app and change the port, the application name, or whatever, it would be very surprising for that to result in the loss of your session, particularly if you were working on checking that session persistence was functioning correctly at the time.

[joshlong]

I quite like the idea of using spring.application.name to inform the cookie name. But make it so that it only happens IF the user has NOT specified server.session.cookie.name (i forget if that's the actual property name but it's something like that). If they have specified it, then we leave it be. If not, then this won't make break anything. People will have broken apps already if they're not using etc/hosts or 127.0.0.1 vs localhost or something. They can continue to do that and nothing will change. But new apps will work better OOTB. I was years into my journey before I realized how stupid http cookies are. You could even put something on TRACE output telling people you've default the cookie name.

[joshlong]

And make it some combo of spring.application.name + server.port would be even better

[rwinch]

A few additional points:

• Changing the name is easy if users knew it was what was causing the problem. The driver for this is isn't just to avoid having to set a property. It is to help users that do not know what happened. The fact that cookies are not isolated by the port confuses users a lot. It is very tricky to debug if you don't know that the port doesn't isolate the cookie. This is especially true when users are dealing with an SSO technology that they don't necessarily fully understand either (they are looking for problems with SSO instead of with the name of the cookie)
• The reason I suggest doing this with devtools
  • I felt there was good president for having devtools change default properties given there was already a good list of them that it changed
  • it is unlikely to be a problem in production where a unique host is going to be used. I also thought that
  • We also should prefer avoiding defaults in production that makes it any easier to fingerprint the application.
• Application name is not guaranteed to be unique, but there will not be applications using the same port running at the same time

[Kehrlann]

This is a recurring issue for anyone running a Spring Auth Server locally, which leads to surprising issues (e.g. infinite redirects to a login page, or bizarre 400 errors).

To reiterate, this is specifically on localhost, or occasionally 127.0.0.1. We could discriminate on the Host header, but I guess we probably want to avoid putting this kind of logic on the hot path? And this would be server-specific implementations.

We could also explore putting WARN logs for invalid sessions, scoped localhost, that hints at this specific issue.

[wilkinsona]

The fact that cookies are not isolated by the port confuses users a lot

To my knowledge, we haven't seen any evidence of this confusion in Boot's issue tracker. Can you please link to some examples so that we can see users' experiences first-hand?

Application name is not guaranteed to be unique, but there will not be applications using the same port running at the same time

This isn't strictly true. By using different addresses, IPv4 vs IPv6 etc, it's possible to have two processes listening on the "same" port.

Edit: perhaps it doesn't matter as the different addresses are then sufficient to separate the session cookies? That said, we've seen some quirky behavior in Boot's test suite where a combination of binding to localhost, whether the JVM prefers the IPv4 or IPv6 stack, and what other processes are listening on the "same" port caused failures as the test connected to the wrong process. FWIW, this investigation suggests that the cookies wouldn't be sufficiently isolated if its findings still occur today.

What do other web and security frameworks do to address this? It sounds like it should be a common problem. Perhaps there's some prior art that could provide inspiration and solve the problem in a recognised way that's, therefore, less likely to cause unwanted surprises.

[Kehrlann]

To my knowledge, we haven't seen any evidence of this confusion in Boot's issue tracker. Can you please link to some examples so that we can see users' experiences first-hand?

Here's an example from Spring Auth Server: spring-projects/spring-authorization-server#852

What do other web and security frameworks do to address this?

IIRC Rails cookies are named _<appname>_session or something similar.

It sounds like it should be a common problem.

We mostly notice it when doing SSO, with a Spring client and a Spring auth server. This is a peculiar combination, few frameworks support implementing both at the same time / in the same project.

[wilkinsona]

Here's an example from Spring Auth Server: spring-projects/spring-authorization-server#852

Thanks. From that issue, this caught my eye:

redirect uri validation rejects localhost as the host for a client

AIUI, this means that you'll still have to use two different hosts to get things to work. That makes the potential disruption of a change to the default harder to justify.

I'm still interested in further examples, particularly those where just changing the name of the session cookie is sufficient to fully address the problem.

[Kehrlann]

redirect uri validation rejects localhost as the host for a client

This used to be the case, but no longer: localhost is a valid host for redirect URIs. Unsure exactly when this has changed, I'd need to ask Joe.

I use a custom session cooke in the samples for the Spring AI mcp-security project to avoid having to fiddle with /etc/hosts. Samples + authorization server config, notice how localhost is used in redirect URIs.
I also use this trick in a commercial project, an auth server for local testing shipped as a jar, that you run on your local machine.

I'm still interested in further examples, particularly those where just changing the name of the session cookie is sufficient to fully address the problem.

Will check if I can find other reports from the community .

[joshlong]

Hi - this issue is something I deal with all the time. i standup an auth server, an oauth client, and an oauth resource server. im going to do this - a new resource server and client - at least four different times in a single talk im doing at devnexus, for that matter. The auth server and the client both use HTTP sessions, so I need to use 127.0.0.1 and localhost for the other. I do this so quickly that I've had people ask me how come it doesn't work for them, not realizing that I used the two hosts discriminately and deliberately, and that they're not interchangeable. Some sort of sensible default here would be both very useful for folks using Spring Security (which should be everybody.. isnt spring security one of most widely used projects) and Spring Session (tons of people).

[wilkinsona]

I think there are competing requirements here.

Consider a situation where you're using Spring Session and have just set up Redis to store your sessions. You now want to launch two instances of your app and check that they can both talk to Redis and share session information. Now consider a separate situation where you need to run multiple different apps at the same time (Josh's scenario above for example). The first situation is well served by the current default session cookie name as the two instances of the same app will use the same cookie name. The second situation is poorly served by the current default as the apps' cookies will clash.

The issue title proposes making the session cookie name unique per port. The second situation will improve as the cookies' names will no longer clash but the first situation will get worse as the apps will no longer share the same cookie. In short, there may be a problem here, but using the port isn't a solution as it just moves the problem from one scenario to another rather than solving it.

@philwebb's idea to use the application name feels like a better approach. It doesn't break the first situation where the two instances of the same app would have the same application name. It should also help with the second situation, assuming that each different application has a different name.

start.spring.io already configures spring.application.name for every app that it generates so encouraging its use has already begun.

I still have reservations about tying together the session cookie name and the application name as I think it has the potential for causing unexpected and confusing breakages for those that don't realise that changing the application name will also change the session cookie name. Rails has the advantage that every application (AIUI) has to have a name so there are fewer permutations to deal with and it's a more firmly established core concept.

I also have some reservations about the application name becoming externally visible. It's previously been private and it becoming visible to the application's clients may be information leakage that a user would not want. I think we'd need to tread carefully introducing it as a new default.

[philwebb]

I'm becoming more and more convinced that whatever option we pick will have drawbacks for someone and we should probably leave the decision in their hands. I wonder if we can offer a quick way to add a qualifier to the session name?

Something like:

server.servlet.session.cookie.name-qualifier = NONE / APPLICATION_NAME / HASHED_APPLICATION_NAME / PORT

That means for demos you can add a one-liner and briefly talk about why it's required. We can also document the pros/cons of the approaches. You could also set the property in your global devtools properties if you really want to.