I have a Spring Boot (1.5.8) webapp, with several other Spring Boot services, all deployed to AWS. The webapp module is deployed to two EC2 instances managed by an Elastic Load Balancer. The whole system is orchestrated by Kubernetes.
I'm trying to set the session cookie max age to work around a problem, as suggested here: Spring-SAML Endless redirect loop after a successful authentication
When I run on my local machine using Docker Compose, all I do is set server.session.cookie.max-age in the webapp's application.yml and it works.
The same thing doesn't work in the Kubernetes-managed system. The webapp has an env actuator endpoint set up and I can see that the max-age setting was applied, but the cookie still has "session" expiration.
The session cookie is named JSESSIONID on my local machine, but just SESSION on the Kubernetes cluster. Why is that? Is the session cookie managed at some higher level in that system, like by the load balancer or Kubernetes itself? I'm pretty lost at this point, so any suggestions would help.
OK, it turned out that the session is being managed by Spring due to spring.session.store-type being set to redis in the integration environments. It's none in my local build, which means Tomcat manages the session instead. Sorry, I didn't mean to obfuscate that. I just didn't know what to look for. The default session cookie name for a Spring-managed session is SESSION, while for Tomcat, it's JSESSIONID, so I was at least right about that being the key to the mystery.
There don't seem to be properties for configuring the Spring session cookie, but I found this explanation about how to configure it in code: Spring Session - Custom Cookie