http://coldfusion.com logo
Join Slack
Powered by
I'm having an issue with my jsessionid immediately...
# cfml-general
d
I'm having an issue with my jsessionid immediately deleting itself once set. I am using ACF 2018 on a Mac and CommandBox to create the CF instance. It has been working fine for months, but all of the sudden I am having trouble logging into my development site. I noticed that after I submit the login form, that the jsessionid appears in my session cookie list, but then immediately disappears and I am redirected back to my login page. I haven't changed my CommandBox config, so I am not sure why this started acting this way all of the sudden. Any thoughts as to where to look for a possible remedy?
b
Check • ssl only cookies • does the domain change • Are you deleting it in your CF code (I've actually seen that one a lot)
d
I'm not explicitly setting SSL Only cookies and the domain remains the same. I haven't changed any login logic in a number of years, so I don't believe that I am specifically deleting the session cookie, but I will need to review my code.
b
Oh, also check for switching between HTTP and HTTPS after login
I recommend making a basic hello world .cfm page that does nothing more. Hit it, and refresh, seeing if your session cookies change or your actual CF session changes.
If that works, start adding in bits of your app to find the issue, following the URLs and cookies in your browser debugger's network tab
d
Thanks, Brad. Since there hasn't been any major updates to the code, I guess that it is just going to have to be a slow process of trying to figure out where the needle is in the haystack of code. I was hoping that it would be just a simple setting that I inadvertently deselected, but that doesn't appear to be the case. Thanks again, I appreciate your help.
b
Did you recently change versions of ACF or CommandBox?
d
I didn't change ACF, but I do believe that CommandBox checks for a new versions of itself upon launching and upgrades automatically if found. I see brief messages related to this in the console, but those are immediately deleted and replaced with the CB logo upon successful start of Box.
b
CommandBOx does not upgrade automatically
It will check for new versions, but it does not clear the messages. The messages are just informational, so clearing them would defeat their purpose 🙂
It's possible you ran the suggested command to update CommandBox, but that would have been a manual step on your part
What version of box are you currently on. There was a CommandBox release last week so anything is possible
d
I am on 6.0.0+00787. I am simply running "box" from the command line without any switches. Though, I just went back and apparently, I hadn't scrolled back up far enough and I do see the version compare messages that I had missed before. Thanks for clarifying that CB doesn't auto-update.
b
It's possible CommandBox 6 has a regression related to this. The only thing I can think of right off is I know there is a setting to have session cookies be SSL
I'm curious if it could be getting turned on but you're accessing the site via HTTP. Just an idea
d
I think that that may be the issue. I noticed that if I try to submit any changes in the CF admin that it errors. Looking at the error log, the error is "coldfusion There was an error while verifying the token. Either the session timed out or un-authenticated access is suspected." Doing a Google search, I found some discussions related to this due to the app trying to use secure cookies over http.
b
You can test this easily by inspecting the cookie header coming back from the server and then looking at the cookie header going BACK to the server on the next requet
First check • if you're hitting the site over HTTP or HTTPS • if the server sends a cookie header with the SSL Only flag • If the browser sends it back to the server on the next request
Just open your Chrome debugger, go to the network tab, and check "preserve log"
d
Yeah, it is definitely sending the secure cookie flag. Since I can't save any setting changes in the CF admin, I'll see if I can explicitly set this to false in my CB server config file.
b
What's interesting is it defaults on false in CommandBox
So I would think it was getting turned on somewhere
d
I can see it set to false in the CF admin, so something funky is going on.
b
I'm not entirely sure who controls the session cookies, especially when Adobe is deployed on something other than it's default Tomcat install
usually it's the servlets job to handle those cookies
Either way, try this
Copy code
server set app.sessionSecureCookies=false
which will modify your 
server.json
And maybe just check for an existing setting first
Copy code
server show
And if you could, maybe DM me a JSON file first from your running server just to look at
If you right click on your tray icon and "open" > "server home", send me the 
serverInfo.json
from that folder
That is how CommandBox stores all the settings that control the server starting up as of CommandBox 6
There is a top-level
Copy code
"sessionCookieSecure":"false",
setting in that JSON. I want to know if it's going across as true or false
That is passed to JBoss Undertow, the servlet container used by CommandBox to run servers
It goes into the 
ServletSessionConfig
object, which is supposed to override how sessions work for the server
d
Off course, I added the sessionSecureCookie setting right before you follow-up to show you the config first. Oh well.
b
No worries, did you check and see if there was already a setting turning it on before?
d
It was definitely not defined in my server file prior, but it is now. I restarted the server instance and got the same response.
👍 1
b
Dang, ok. Well that may have been a red herring then
I can't imagine what would be forcing that session cookie to the SSL-only unless you had an Application.cfc setting or something affecting it
d
Also, the tray icon that I see is a java icon (with the CF logo) and it does not give me an option to open server home.
b
Screenshot?
d
I considered the Application setting as well, but none of them point to secure cookies either. this.clientManagement = false; this.loginStorage = "session"; this.sessionManagement = true; this.sessionTimeout = createTimeSpan(0,1,0,0); this.setClientCookies = false; this.setDomainCookies = false; this.scriptProtect = true;
Screenshot 2024-02-23 at 4.49.53 PM.png
I tried the Show in Finder, but that doesn't do anything.
b
That's not the icon I'm talking about
ON mac, it's in the upper right hand corner I think
I'm a windows guy, but it's the equiv to our system tray
oh wait mac
lol
We turn off the tray icons on mac by default now due to some incompats with our system tray library
So you don't have a "tray icon" unless you re-enabled that feature yourself
sorry
I forget Mac users are still a thing 😆
It's just this folder
Copy code
server info property=serverHomeDirectory
That command outputs the path to the same server home the tray icon would have opened for you
d
Okay, I just DM'd you with that file.
@bdw429s Just following up on the issue that I was having, I think that I boiled it down to cookie domain. If I watched the cookies tab when hitting my a page, I would see the jsessionid cookie flash on the screen and immediately be removed. I had to take a screen recording of the behavior in order to be able to capture what was being set. I normally use the domain convention of localhost.clientdomain.com for each of my development sites, have done so for years. However, when I looked at the domain that was being used for the session cookies, it was .clientdomain.com, localhost was missing. I am assuming that because the domain is a mismatch, that the browser was deleting the cookie. I changed the host setting in my CommandBox server.json file to use clientdomain.localhost and this fixed the issue. I have been using CommandBox with localhost.clientdomain.com since July and have not had any issues until last week. I'm not sure if it is CommandBox issue, Java issue, or CF issue, but it is fixed. I just wanted to thank you again for you assistance and to let you know what the resolution was.
b
@Dean Lawrence Thanks for getting back. I did some testing yesterday spinning up a test site on Adobe CF and was unable to reproduce the behavior. The domain is an interesting twist
Are the cookies still be created as secure though? Because I would think that was still an issue 🤔
Also, can you show me the 
Application.cfc
settings you have for your client cookies so I can replicate the setup?
It is common to use
Copy code
.domain.com
as your cookie's domain as a sort of wildcard which is supposed to match
Copy code
sub1.domain.com
sub2.domain.com
I assume you have some config in ColdFusion that is setting the domain?
Actually, I think the 
Application.cfc
only has
Copy code
this.setDomainCookies = true
You have to re-set the cooikie manually with cfcookie to override the domain I believe
Do you have code like this somewhere in your app?
Copy code
<cfset domain = ".example.com">
<cfcookie name="jsessionid" value="#session.sessionid#" domain="#domain#">
d
Here are my application setting that relate to cookies and session. this.clientManagement = false; this.loginStorage = "session"; this.sessionManagement = true; this.sessionTimeout = createTimeSpan(0,1,0,0); this.setClientCookies = false; this.setDomainCookies = true; Since I am using CommandBox, I am setting my host name in the server.json file. I scanned my code and I am not setting or overwriting the jsessionid cookie. It is really bizarre as it has worked for months and then just stopped. But, it is working with using the new host name, which I can live with. Oh, and the jsessionid cookie does still display as secure, but is being loaded without error. 🤷‍♂️
b
Wait, you're using 
setClientCookies=false
?
How are you going to track your session without client cookies?
When you use that setting, you're required to put the CFID and CFToken in every URL to keep the session
d
That is only if you are not using J2EE session.
b
Sorry, I don't follow
d
Yeah, if you turn that off, those two cookies are not create, but their values are still available in the URL token of the jsessionid cookie if you want to use them.
b
I've never seen anyone actually using session management with client cookies turned off. That's like, from 1998 when cookies were new
Basically, you'd be dependent on the servlet ot maybe set a session cookie- which seems a little sketchy to take it out of CF's hands
CommandBox 6 does have some minor Undertow updates-- it's possible it's changed how it adds session cookies.
d
There are just a number of variables at play with the browser publishers tweaking things a lot since the beginning of the year, so it is hard to say if it is CommandBox or a browser oddity.
b
Right, I'm still just stuck on the fact you've turned off CF's handling of session cookies, but you still want to use session cookies. I've never heard of people actually doing that, lol
I have no idea what servlet's do when they set session cookies. I don't typically depend on my servlet to set those!
d
I've been doing it that way for at least 10-15 years. When they were introduced there were issues with session hijacking and using the j2ee sessions lauded as being a safer approach then CF's built in session management.
b
I just spun up a quick 2018 test server with your settings and i gets no cookies at all
Checking in my browser's debugging
Every compliance scan I've seen tag CF's CFID as a "session highjacking" vuln is stupid because they don't take into account the CFTOken which is required to exist along side the CFID
I always challenge their "finding" with an explanation of how CFID alone isn't enough to get a user's session. You need the token, which adds the needed entropy for security
CFID/CFTOken is just as secure as a jsessionid. Most security scanners just don't know how CF works so they make bad assumptinos when they see it's just an integer
But I still can't even reproduce your cookie with the bad domain. When I configure an app the way you have it, I get ZERO 
SET-COOKIE
HTTP response headers. So no cookies are set at all. I'm not even sure how you're getting one with a domain
Looks like Undertow's configuration for when it sets the session cookies does have settings for the domain you want, but I've never exposed that stuff in CommandBox so you'd just get whatever undertow defaults to.
d
The jsessionid may only get set once you try to set some other session value. I carry some user preferences in their sessions.
Yeah, the whole domain thing is odd. Like I said, it has worked for months, so I am not sure why all the sudden it finds the way that that the domain is set in the cookie as being an issue.
b
Using the session scope in my sample app still doesn't cause a set-cookie header to be sent
One possible difference is I'm using 
127.0.0.1
and Undertow's default session cookie behavior could be based on the host
d
That is true.
Also, in your sample app, what if you just dump the session to the screen, does it create the cookie then?
b
nope, I just get a different sessionID every request
but no set-cookie header is ever sent from the server to my browser at all
So my browser never stores any cookies
Which is honestly what I'd expect when session cookies are turned off
I even switched over to a domain
d
When I clear my cookies for the site, the next page I hit sets the cookie.
b
I don't see a domain on that cookie
I thought you said the cookies were coming with a 
.<http://something.com|something.com>
domain
AFK: picking up kids from school...
have you configured CF to use J2EE sessions?
d
I see the domain when I look at the cookies section of the Application tab in Chrome. I am no longer seeing the somthing.com since I changed my hostname to something.localhost.
Ah, yes, that would be why you are not seeing the jsessionid being created, you need to change your sessionType from cfml to j2ee.
Thanks again, Brad. Have a good afternoon.
b
I had put this in my 
Application.cfc
but I'm unclear if ACF 2018 support this
Copy code
this.sessionType="j2ee";
Enabling it in the CF admin has made the cookie appear now
It has the current domain, and secure is NOT true
Looks like if I keep refreshing the page, the jsessionid cookie value stays the same
d
Yes, that is the behavior that I have now.
b
And you still can't stay logged in?
d
I can now stay logged in since I change the domain.
b
So, how do I set up a test with the broken configuration?
What was your domain set to before?
d
What I was experiencing is that I would literally see it flash in the the cookie in the cookie panel and then it would be immediately removed. Because it was not persisting, I couldn't log in.
b
Right, I remember. Now how do I test that 🙂
d
My domain before was localhost.domain.com. I changed it to domain.localhost and it now works.
b
And are you using the host-updater module or a manually-configured hosts file for that domain to resolve? What IP is it resolving to?
d
I manually added the localhost.domain.com to my host file and it resolved to 127.0.0.1. I have not done that with the new domain.localhost. I simply added the following to my server.json file.
Copy code
"web":{
        "host":"domain.localhost",
        "http":{
            "port":"8080"
        },
        "rewrites":{
            "enable":true,
            "config":"customRewrites.xml"
        }
    }
b
I changed my domain to match yours exactly, it the cookie still seems to work correctly
image.png
d
Like I said, it worked for months for me as well. It only started acting up last week.
b
I can't imagine how you would have gotten a domain as 
.<http://domain.com|domain.com>
unless you had hit a server that specifically set a cookie with that name and your browser just remembered it
is there a chance your browser visited that domain but hit a staging server by chance using SSL and a custom cookie domain
And then your browser tried to keep using that cookie from the staging server with our local dev server?
d
Yes. I have both a staging and live server that share the domain, just different subdomains. Both the staging and live server use ssl. But, I've never had this issue before.
That is why I was wondering if it was something that changed in Chrome or CommandBox that may have caused it to stop working.
b
Right, but until we can define what "it" is we can't figure out how "it" used to work and how "it" works now and what changed 🙂
Does your production site use a custom cookie domain?
If you visit your prod site, do you get a session cookie that is secure and a generic domain like 
.<http://domain.com|domain.com>
If so, your browser would likely try to use that cookie on dev because it would match the domain
d
No, I'm not using any domain setting on cookies. Actually, I don't think that I am actually setting any implicit cookies, just session variables which are based on the single session cookie.
b
Note, this doesn't have to come from ColdFusion
If you have a random PHP blog running on 
<http://foobar.domain.com|foobar.domain.com>
whicih sets a 
jsessionid
cookie with a domain of 
.<http://domain.com|domain.com>
that could do it
Basically, ANY site you may have visited in the past that may have put that secure wildcard domain cookie into your browser
It just worries me that I had another report this morning similar to yours https://cfml.slack.com/archives/C06TSRXCJ/p1709017909504259 but I haven't heard back from the OP to be able to drill into his setup yet
d
Hmm, interesting. I don't think that I have anything else running, but I will have to make sure. This site runs its own VPN, so there aren't any other sites outside of it. But, perhaps the marketing guy set something up that I inadvertently looked at.
b
And just for reference, CommandBOx 5.9 to 6.0 updated from Undertow `2.2.24-Final`to 
2.2.28.Final
d
Gotcha. This site is an old Model-Glue site which loads all the framework components on onApplicationStart(). I do have a onRequestStart() method that looks for a reload variable to reinitialize the app when component changes have been made. Let me play with removing some of those actions and see if I can get the old configuration to run again.
b
Here are all the changes in Undertow since 2.2.24 BTW. I didn't see anything to interesting right off https://issues.redhat.com/issues/?jql=project%20%3D%20UNDERTOW%20AND%20fixVersion%20i[…]Final%2C%202.2.25.Final%2C%202.2.27.Final%2C%202.2.28.Final)
d
Okay, I'll look this over and run some additional tests. I'll touch base tomorrow to let you know if I've got any more info.
3 Views
Open in Slack
PreviousNext
Powered by