Legacy authentication fails when upgrading from Coldfusion 10 to 2023

[derekn911]

I recently installed Coldfusion 2023 on a new server and got it configured to run my applications previously running on Coldfusion 10.  As I started to migrate applications, I discovered that all of them that utilized a legacy application.cfc authentication script now throw the following error:

Failed to set cookie.

ColdFusion is unable to add the cookie you specified to the response. This is probably because you have used it to set one of the ColdFusion Session Cookies or Authentication cookie. Please use Application/Server level configuration for this.

The error occurred in E:/InetPub/wwwroot/ad_authentication_XXXXXXX/XXXXXXXX.cfc: line 17

15 : 16 : <cffunction name="onSessionStart"> 17 : <cfcookie name="CFID" value="#SESSION.CFID#" /> 18 : <cfcookie name="CFTOKEN" value="#SESSION.CFTOKEN#" /> 19 : <cfset SESSION.DateInitialized = Now() />

I googled this error and found information regarding a setting change in CF Administrator.  I went into my CF Adminsitrator > Server Settings > Memory Variables and unchecked the "Disable updating Coldfusion internal cookies using Coldfusion tags/functions" option, restarted services, and tried to hit the page again only to receive the following:

This site can’t be reached

xxxxxxxxxx.xxxxx.xx took too long to respond.

Try:

• Checking the connection
• Checking the proxy and the firewall
• Running Windows Network Diagnostics

ERR_CONNECTION_TIMED_OUT

I then checked the Application.LOG and see the following

Application.Log

"Error","ajp-nio-127.0.0.1-8022-exec-2","10/25/23","08:56:07","laptops","Failed to set cookie.ColdFusion is unable to add the cookie you specified to the response. This is probably because you have used it to set one of the ColdFusion Session Cookies or Authentication cookie. Please use Application/Server level configuration for this. The specific sequence of files included or processed is: E:\InetPub\wwwroot\xx\xxxxxxxxxx\xxxxxxxxx.cfm, line: 17"

*****the lines that follow appeared after I made the change to CF Administrator Memory Variables*****
"Information","http-nio-8500-exec-9","10/25/23","09:01:39","xxxxxx","Session rotated successfully."
"Information","http-nio-8500-exec-9","10/25/23","09:01:39","xxxxxx","Invalid login for user xxxxxx"
"Information","http-nio-8500-exec-3","10/25/23","09:01:47","xxxxxx","Session rotated successfully."

The "xxxxx" above appears to reference the username that I use to access the CF Administrator.  In checking the logs from the CF 10 server, I see similar "Session rotated successfully." lines, but the "invalid login for user XXXXXX" line is not present, nor is the reference to the username "xxxxxx" within the rotated successfully reference.  See below for CF10 server log regarding similar lines.

Old server:

I am at a loss as to how to resolve this and could use some guidance.  My guess is that it has something to do with the invalid login inbetween the session rotated successfully lines, but not sure 1) why CF2023 references the username in that line while CF10 does not, and 2) Where to even begin troubleshooting this issue.

[Charlie Arehart]

Derek, there is much that could be said, both to diagnose and perhaps better configure your code and admin (or app) settings regarding these cf session cookies.

But let's start with the simplest thing to try: either a) in your browser clear the cookies you have for the site in question and try again, or b) in your browser try opening a new private window/new incognito window and try again, or c) visit the site in a new browser that's not visited the site before.

If that doesn't "solve things ", there can of course be many things amiss...and not "mistakes" you made but default configurations of either cf, the web server, or the OS (of this new machine) which differ from the old machine.

It will not be impossible to resolve things, but it may prove very challenging "playing battleship" here in the forums to sort things out.

Maybe the above suggestion would get you going (though you may be concerned about having end users resolve things). Or we may in back and forth find something else. Or maybe someone else here may solve your issue. But if not, if you remain "at a loss", not aware "where to even begin", I'll say that I help folks solve such problems daily on a consulting basis, via remote screenshare. More on my rates, approach, satisfaction guarantee, online calendar and more at carehart.org/consulting.

But again I and perhaps others here are game to try to work things out here, to the degree it's feasible. There are just a lot of moving parts in your setup (the code, the app, the admin, the web server, the os, your browser), any of which may be the cause or solution.  

[China-Buy_com]

Did you resolve this problem?

I'm having the same issue.

[Charlie Arehart]

Derek never replied before now, of course. If he does not offer a solution in reply to you, I hope you'll at least consider what I wrote to him above.  And is your situation exactly his? I'm gathering you got the same error message, which is perhaps how you found this post.

If so, did you uncheck "Disable updating Coldfusion internal cookies using Coldfusion tags/functions"? What happened then? He says he got a hanging request after that. Are you also? As we never heard more, perhaps that had a different explanation (maybe once his code got past that cfcookie that was failing, it hung up on something else unrelated to this issue)?

Or have you not yet made that setting change, perhaps in fear that it won't solve this error message? It will, and the only negative consequence is that you're disabling a protection Adobe has offered (in that setting) since cf10. It's about protecting modification in code of these specific CFID/CFTOKEN and/or JSESSIONID cookies, used for CF session management.

(That said, the option to disable that is checked by default only if one enables the "secure profile" feature at cf installation or via another page in the cf admin. Of course, someone can change the setting itself as discussed above.)

But let's take a different approach to your (and their) problem; folks who are doing that cfcookie--setting cfid and cftoken to have no expires attribute--are doing that to cause an effect that the cookie goes away when the browser is closed. That's a security protection they want (or someone in the past wanted).

Well, note that this can be achieved (without your code touching the cookie) by using ANOTHER setting at the bottom of that same memory variables page: setting "cookie timeout" to - 1. Sadly, it's not indicated there and its barely documented.

Or--if you can't or don't want to do that change at the cf admin level (which affects all apps on the server), you can also effect that change at the application level, whether in cfapplication (application.cfm) or application.cfc. You can also control that ability to disable the cf session cookie updates. The docs have examples of doing it in application.cfc, but they don't show doing it in application.cfm and with cfapplication. Here is one example that could work for you:

<cfapplication sessionmanagement="yes" sessioncookie="#{timeout="-1",disableupdate="no"}#">

<!--- this example shows setting only the least attributes needed to demonstrate this issue. You may need to add more attrbutes for your app, of course, such as sessiontimeout. Or you may need to add more struct keys for the sessioncookie. Also, FWIW, the sessioncookie value above could be written  without quoted values as {timeout=-1,disableupdate=false} --->

Note also that you can prove that you've effected the change by doing this:

<cfdump var="#getapplicationmetadata().sessioncookie#">

which will show what settions are set for the various aspects of this sessioncookie struct.

In fact, you may want to do that first WITHOUT the change above, to see what your sessioncookie settings are by default. You would then want to consider whether to set those other cookie settings as well. Note the sessioncookie attribute simply takes a struct of keys, which again are documented by Adobe here, though they show using the sessioncookie only in application.cfc instead.

All that said, if you DO find tht setting the cookietimeout is sufficient for your needs, then you may want to NOT change that disableupdate feature, as again it's "true" for your protection. But at least this lets you control things at the app level.

Let us know if any of this gets you going, Derek, or at least I hope it may help future readers of this page.