CF911: Solving problem in ColdFusion Admin getting "error accessing this page" on certain actions

Note: This blog post is from 2014. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

And your operation fails. You're then prompted to "Click here to login", but even if you back up or client another link, you'll be prompted with the CF Admin login.

What gives? Why is it happening? And how can you fix things? Is CF broken? No, not in the sense that you need to reinstall or anything. The good news is that there is a quite simple solution. Well, there are several, depending on your goals.

The simple solution: delete the duplicate cfid/cftoken or jsessionid cookies that you will find your browser is sending to CF. But there is much more to this, as well as other solutions, which would be worth most readers taking a few minutes to read on here.

BTW, the same root problem can be the cause of your own application's users finding that they can't stay logged in. More on that in a moment.

What is happening?

First, let's note that the problem doesn't happen when you login to the Admin, nor even when you click around visiting different pages in the Admin. It happens when you click on features that involve a form submission, such as when you make pretty much any change, or when you click buttons like "verify all connections" in the Datasources page, or click the "check for updates" button on the Server Updates page. All these cause CF to do some processing that's different from just visiting a page. (I suspect it's an issue with CFLOGIN, but I'm just guessing.)

Second, let's point out that the problem of the CF Admin getting that error above need not be as mysterious and irreconcilable as some make it out to be. There actually is more information in the logs, if you just go looking for it, either the application.log or the coldfusion-out.log (if using Windows, or it may be the cfserver.log on *nix, or the console log if launching CF from the command line or CF Builder).

In the coldfusion-out.log, you will find that this error appears at the time of the error:

And in the application.log, this one appears:

Now, both messages give a bit of a clue as to what's going on. Your session has rotated, but then there was a problem with CF verifying the "token". Any guesses what that "token" is?

Spotting the problem

Some will recognize that the "token" is (typically) the cookies used by CF for managing sessions, which may be CFID and CFTOKEN or JSessionID if using the "J2EE sessions" feature (which is settable in the CF Admin, on the "memory variables" page).

The problem here is that (for any of various reasons) CF sees duplicate cookies for the tokens it is wanting to use, and being confused, it is just giving up.

The good news is that there are several workaround, as I will show in a moment. (Sadly, the Adobe bugbase entry where someone raised this issue says that there are "no workarounds", when in fact there are several, as I will show.)

If you use any sort of browser dev tool or "proxy/sniffer tool" (now built-into all the major browsers, as I've spoken about before), you'll most likely see you have 2 CFID and 2 CFTOKEN cookies, or 2 jsessionid cookies being sent from your browser to the server.

The issue is that they are different enough, whether in the "case" (upper or lower) of the cookie name, or with different domain values, path, or other attributes, by which the browser thinks they're different enough to send both cookies (of the same name) to your server.

And CF gets confused by this.

How the duplicates got there is a subject for another day. (Someone in the bugbase suggested it happened for them because they had CF9 and 10 on their one machine. I just had it happen on a machine with only CF10, but I do happen to have Railo on the machine also, for some testing purposes, and I can confirm that it was setting the lowercase cfid and cftoken cookies, in conflict with CF's uppercase CFID and CFTOKEN.) You may also have the duplicate cookies because YOUR OWN CODE may be setting a CFID/CFTOKEN or jsessionid cookie, and you may be doing it differently from CF, thus ending up with the duplicates one way or another.

An impact of this problem beyond the CF Admin

And as I mentioned in the opening, this problem of duplicate CF session cookies can actually also be at the root of some other problems (besides your use of the CF Admin), such as your own CF web application's users finding that they can't stay logged into their applications, being forced to login again unexpectedly, etc. (And no, you do NOT need to be using CFLOGIN to suffer the problem. I was guessing above that that could be the issue with who only form submissions fail in the CF Admin. I've seen people have their CF applications cause loss of sessions in CF10, or again 9 or 8 depending on hotfixes applied, even if they do NOT use CFLOGIN, for the reasons I outline here.)

As above, you'll find often that in such cases, if you could get the users to look at their cookies (using the same browser dev tools), they would see the duplicate session token cookies, and they could remove them.

And if you are reluctant to try to get your users to confirm this, you could do it yourself by dumping/logging the value of cgi.http_cookie, which holds the value of cookies sent from the browser to the web server. (Note that I am NOT proposing you dump/log the CF "cookie" scope, which could hold cookies created in the life of the request on CF itself, which could be different.) And you could try in your own code to find and remove the duplicate cookies, but that too goes beyond the scope of this entry.

My focus here is to help you get around the error in the Admin, both to explain why it's happening and some easy workarounds you could consider.

Some workarounds

As I said at the opening, DO NOT freak out and think that you need to reinstall CF or something (as many have asserted if you look around the bugbase or indeed the web on this problem).

There are any of several easy workarounds you can use.

The goal of course is to enable you to be able to do whatever operation you had wanted to do, and to do it, you need to deal with that duplicated cookie issue. Some workarounds will be easier for folks than others, depending on the browser/tools you have to manage cookies. You can either:

• Clear just those duplicate cookies, the pair of CFID/CFTOKEN/jsessionid cookies (again, watch the case). CF will recreate them on the next request. (Do a google search to find the way to clear cookies for your browser)
• Or if it may be easier, clear all the cookies for the domain (if you're using localhost, clear all those for localhost), or worst case (I hate this advice) clear all cookies from your browser. That's a last resort.
• You could also simply try visiting your CF Admin using a URL that's different from what you've been using, but which gets you to the same CF instance (such as using localhost instead of 127.0.0.1, or vice-versa, or using an IP address rather than your domain, etc.) The browser will only send cookies to a server that the server (that named domain or IP) has sent to the browser in the first place. If you've been visiting the CF Admin with one ip/domain name, and not some other that would work, you will find in visiting from that "other one" that it may not have the duplicate cookies (yet), and so you may now get into the Admin, no problem. Of course, if you HAVE visited the admin or other pages on your site using that domain/IP, you may run into the same issue in accessing the Admin
• You could try visiting the same Admin URL in a different browser. For instance, if the failure happens when using Chrome, try Firefox, IE, Safari, or Opera, and vice-versa. The key is, if the other browser is one that you've not visited the CF Admin/site using, then it won't have the cookies (or may not have the duplicates), so won't have the same problem.
• If you only have one browser installed, if it's Chrome or Firefox, you could try visiting the CF Admin in an "incognito window" (in Chrome) or a "private window" in Firefox (search for more on these features). These features open a new window in your browser which is supposed to make you appear rather anonymous, such as not tracking your history, not sending cookies that have been sent before. I find the tools to be uneven on that last point, but it's worth a try.
• If you ARE using "J2EE sessions" in CF, since the jsessionid (at least that created by CF) is a "session cookie" (meaning it lives only in the memory of the browser), you may also find that if you simply close the browser and re-open it, that may clear the cookie (whether you have to close all windows of the browser will depend on the browser and how it shares such session cookies between windows. I discussed this in an article on J2EE sessions when they were added to CF6, in 2002. The characteristics of IE and Firefox (and Chrome) have not really changed in this respect since then.
• Following on the previous point, if using J2EE sessions, you may find that simply opening a new window of your browser it may not bring in the jsessionid from the other window. Again, see the 2002 article for more on that.

Any of these should get you past the problem, at least temporarily, so that you can proceed to do whatever you wanted to in the CF Admin that was failing to work.

Long-term solutions

Again, though, the long term solution is to find and resolve whatever is creating the duplicate cookies, or put in place some code to find and remove them. That's beyond the scope of this entry, but I wanted to get the above out as I see folks often hit the problem on their CF Admin, including customers of my CF server troubleshooting services.

Could be your application

I'll also note, as you may want to explore this more, that the problem may be due to your own application's manipulation of the CF session token cookies. People for years have done this with the CFID/CFTOKEN cookies, for instance, such as to set them "again" using CFCOOKIE but with no EXPIRES attribute, which causes CF to set the cookie without any expiration value (to prevent it being stored on disk) which makes it into what the browsers consider a "session cookie" (like was described above with respect to CF's "J2EE session" cookie, jsessionid).

But in doing that, they may leave out some attribute that causes the cookie to be different than the one CF sets. Again, this is where those browser dev tools can be handy: you can see what cookies ARE being sent to your browser from CF, and maybe you will spot what's amiss, and where it's happening.

It can be difficult to solve, though, because the cookie may be set in some application (on your domain) that you're not thinking of or testing. Nothing tracks what page in your site sets a given cookie (that would be a pretty cool addition for some browser to add), so it could be anywhere in your domain.

This is also why this problem is so challenging when a user gets it (not with respect to them accessing your CF Admin, of course, but when they're having problems staying logged into your application.) You may have a hard time finding first which users, if any, have the problem. Then you may have a hard time finding what page is setting the cookie that's creating the duplicate. It can be a real pain.

You might consider switching session variable approaches

Finally, still another long-term "solution" might which you might consider is that if you were NOT using J2EE sessions, you'd find that if you DID change to using them, it could seem that the problem was "solved". Same with if you WERE using them and switched to NOT using them. (But to be clear, it's possible that it may only hide the problem temporarily.)

What's happening is that now your browser will be given a different session cookie (jsessionid for j2ee sessions, cfid/cftoken for regular CF sessions), and initially that "other" kind of cookie would not be duplicated like your first kind was.

But whatever caused the duplication of the other kind would likely lead to duplication of the new session cookie eventually. So making this switch may or not really be a good long term solution.

(I would point out, also, that switching to or from J2EE sessions is not something to do lightly. There are important implications of doing it which could affect your application and how it works for users. I discussed this in more detail in an article when the feature came out, New Possibilities for Session and Client Variable Handling in CFMX (CFDJ, August 2002), which should be as relevant today as then.)

You might want to reconsider the "session fixation protection" feature

All this problem really is rooted in a change that Adobe made (in 2011, available as a hotfix for CF 8 and 9, but included automatically in CF9.0.2 and CF10) related "session fixation". It's that feature, a protection mechanism meant to help prevent session hijacking, which really seems to make CF so sensitive to this issue of duplicate cookies. You can do a google search for that topic to find many others in the CF community who have talked about that, and some workarounds available to disable that, which involves setting a jvm argument to coldfusion.session.protectfixation=false. It's a rather drastic solution to the problem, but especially if the issue is more about your application users having problems, versus just CF admin access issues, then it may be worth considering.

And while one may want to consider removing the security hotfix (more later) which introduced the issue for CF 9 or 8, that may be overkill. And note that there's no hotfix you can "remove" in CF10 to address this. The session fixation protection is built-in from the first CF10 installation. But one could tell CF to disable the session fixation protection. Again, I think that's overkill for the problem described here (the CF Admin issue), but you may want to consider if if it's the cause of your session loss problems in your applications. Again, just see the other discussions you find googling as mentioned in the previous paragraph for more on that.

Reconsider the CF cookie settings

Finally, at the same time CF added new features that changed how it (CF itself, setting cookies) and your own code goes about creating cookies, which might increase the chances of your own code (unexpectedly) creating the duplicate cookies.

Some are changes in the CF admin Session Variables page, others are in the cfapplication tag or variables in the "this" scope of application.cfc, and some are in the CFOOKIE tag itself.

For instance, CF10 has added a new encodevalue attribute for CFCOOKIE, and its default is true, so that CF now creates the value of a cookie as a URLEncoded value, which means that if it has special characters, those get converted into a URL-safe character entity. That's fine, except that if it causes your code to create a value that's not quite the same as CF would create itself, that may start this problem of your having duplicates.

I don't want to belabor this point. This entry has gone long enough. I just wanted to share the observation in case it may help some readers take the solution still further for their own needs.

Conclusion

I hope that one of the far simpler workarounds above will help anyone who runs into this core problem, of the CF Admin seeming to be "broken". But when it comes to solving the problem with respect to your application users, it's definitely a thornier one to decide the best solution.

Whether you're one of my consulting customers, or one of my regular readers, or someone who perhaps finds this later trying to search a solution, I hope this this was helpful, both to understand the nature of the problem and its available workarounds, and to consider the larger context.

This is why my blog entries tend to be longer than most. If the problem really was "simple", it wouldn't be so hard for people to get a clear understanding of the problem, its solutions, its broader ramifications, and so on. :-)

For more content like this from Charlie Arehart:

• Signup to get his blog posts by email:
• Follow his blog RSS feed
• View the rest of his blog posts
• View his blog posts on the Adobe CF portal

Need more help with problems?

• If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
• See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed