If you’ve started using Lucee 5.3.9 for your CommandBox servers (which is the new default in CommandBox 5.5) and you have SSL enabled, you may have noticed your session scope getting lost in your application as well as the Lucee administrator.
The TL; DR; is to disable HTTP/2 for now on your server:
server set web.HTTP2.enable=false
This is a regression in Lucee 5.3.9, but it’s really sort of a bug in the way Undertow handles cookies over HTTP/2. It’s complicated but basically, when SSL is activated, your browser will likely begin using HTTP/2 to communicate with CommandBox. Normally all browser cookies are sent in a single HTTP header like so:
Cookie: cfid=123; cftoken=0
But HTTP/2 allows those cookies to be broken up into multiple headers so long as the server re-assembles them into a single cookie after parsing the request. Undertow parses all the cookie headers but fails to re-combine them into a single header.
Cookie: cfid=123
Cookie: cftoken=0
In Lucee 5.3.9, Lucee stopped getting cookies from the servlet container and started grabbing the LAST cookie header and manually parsing the cookies from it. Of course, this means over HTTP/2, Lucee would only find the last cookie and would lose the rest of them. Lucee wasn’t necessarily wrong in what it changed, but it did expose the wonky Undertow behavior in a way that means your cfid cookie probably is getting lost and a new session scope (and cfid) gets created on every request.
Lucee has fixed this already on their bleeding edge: [LDEV-3979] - Lucee
Undertow’s developers are being a little hard-headed but hopefully they’ll “see the light” on this ticket: [UNDERTOW-2082] HTTP/2 doesn't reassemble cookie headers violating rfc7540 8.1.2.5 - Red Hat Issue Tracker
The easiest way to confirm if this is biting you is to open your browser’s debugging and look at your cfid or jsessionid as you refresh the page. If it changes every time, you’re probably hitting this.
To fix, you can try running your server on the latest Lucee 5.3.9 snapshot builds, or just disable HTTP/2 for now.
server set web.HTTP2.enable=false
Disabling HTTP/2 should be minimal impact. This issue also should not affect you if you are terminating SSL at a front end web server and then proxying to CommandBox. It seems to only affect scenarios where CommandBox itself is running SSL and the browser is hitting the server directly.