Hello there!
After upgrading to version 6, we noticed the session cookie settings (app.sessionCookieSecure, app.sessionCookieHTTPOnly) started defaulting to always true. This inherently is not a problem, however, if we try to disable these settings for our local development it doesn’t appear to have any effect. With these settings set to false in our local environments, our JSESSIONIDs continue to reset during the login process and with further investigation into the cookie you can see HostOnly:true and HttpOnly:true.
Additionally, the openBrowser setting does not appear to be taking effect either. Upon initially starting up the server, the site never automatically loads as it did prior to upgrading.
Thanks in advance for any insight you may have!
So, a couple other people have reported this behavior, but it doesn’t seem to affect everybody, I can’t reproduce it, and we’ve not gotten to the bottom of it. It could be related to a newer version of Undertow or a setting being handled differently. Are you using CF session management or J2E session management?
The open browser issue is probably fixed on the bleeding edge. There was a small regression where a custom open browser URL was being used and instead the default one was used. Now, if you’re saying the browser doesn’t open at al, then that’s a new one and you’d need to elaborate. I can confirm I get a browser that opens every time I start a server on CommandBox 6.
Thanks for the quick response, Brad!
We’ve set our CF config to “sessionType”: “jee”, so it should be a J2E session.
You raised a good point about versions, and I just upgraded to the latest - v6.0.1+00790. Unfortunately when I re-tried I’m still not getting a browser to open or to navigate to the “openBrowserURL” I’ve configured. This is odd because if I use the tray icon, and select the Open > Site Home link it opens the browser and takes me right to it. When I start the server I get the “Server is up…” notification and my settings are structured as such:
{ ...
"openBrowser":true,
"openBrowserURL":"http://localhost",
...
}
If there are any other details I can elaborate on, please just let me know.
This is not a dire situation that needs a resolution (especially if it’s just me) since I can navigate to it easily myself, but I wanted to reach-out in case I was missing something simple on my end that I was unaware of.
I just tried running the following commands in a fresh folder:
❯ server set openBrowserURL=http://localhost/my_custom_page.cfm
❯ start
and after a few seconds, my browser opened up to the URL
http://localhost/my_custom_page.cfm
Seems like a likely cause. Can you test switching that to CF sessions just long enough to see if it changes the behavior. Do you have an SSL listener configured on this server?
Also, do you see any difference if you set these to false?
{
"app" : {
"sessionCookieSecure": true,
"sessionCookieHTTPOnly": true,
}
}
Those are passed to Undertow’s servlet configuration, and with J2E sessions, Undertow would be controlling the cookie, not CF. It’s possible the latest version of Undertow changed their default settings and aren’t obeying the servlet config.
Okay, so I did some back-peddling and made a discovery!
I started with a simple, fresh server/test page just like you’ve described, and was able to successfully get the browser to open the page. Then I slowly added my actual server settings in until it broke the browser opening, and I’ve found the culprit to be the “HTTP” binding.
These server.json settings work to open the browser (albeit the page cannot load due to the port):
{
"openBrowserURL":"http://localhost:8085/my_custom_page.cfm",
"web":{
"bindings":{}
}
}
These server.json settings do not open the browser (but the page can load when open manually):
{
"openBrowserURL":"http://localhost:8085/my_custom_page.cfm",
"web":{
"bindings":{
"HTTP":{
"listen":"*:8085",
"host":"localhost"
}
}
}
}
Does this also happen in your testing? Have I misconfigured the binding somehow? I tried different ways of declaring the site binding based on the documentation, but no luck with any of them.
I still need to look into your session suggestions, but wanted to share my openBrowser finding in the meantime. Thanks!
In response to your session suggestions:
Do you have an SSL listener configured on this server?
No, this configuration is just for local development so only running port 80.
Also, do you see any difference if you set these to false?
Not really. I’ve had these turned off from the beginning, but they don’t seem to take effect.
Can you test switching that to CF sessions just long enough to see if it changes the behavior.
Alright, so here’s the fun stuff! The CF Sessions work, the J2EE sessions work, but using JEE does not work. To clarify:
"sessionType": "cfml" // works!
"sessionType": "j2ee" // works!
"sessionType": "jee" // doesn't work, but this is the exact setting in Lucee and what I was trying to use
I’m confused as to why the CFConfig only has the two working options provided in their documentation:
// One of the strings "cfml", "j2ee"
name='sessionType' type='string'
But when you pull up the Lucee server settings (lucee@5.4.3+2), it only provides the “cfml” and “jee” options.
Is there any major difference between j2ee and jee to be concerned with that you know of? It is possible there may be a cfconfig to lucee discrepancy at play?
