tracker issue : CF-3810459

select a category, or use search below
(searches all categories and all time range)

Issue with session rotation in CFADmin

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)

Created: 08/22/2014

Components: Administrator

Versions: 11.0

Failure Type:

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Major / All users will encounter

Locale/System: ALL / Platforms All

Vote Count: 4

Listed in the version 2016.0.0.297996 Issues Fixed doc
Verification notes: verified_probably_fixed on July 22, 2017 using build 2016.0.01.298513
I'm glad I've finally been able to get some metrics on this

95% of the time when I go into CFADmin on CF10 or CF11, I have read-only access no problem, but if I go to change a setting (or verify DSNs, or interact in any way other than reading), I get the following error:

There was an error accessing this page. Check logs for more details. 
Click here to login
(I'll attach a screen cap too)

I used to think this was because I was accessing CFAdmin for various different CF installs / versions on the same domain (localhost), and thought it was "one of those things", but I have just proven it is NOT that, and it's just bungness in ColdFusion.

I am setting up a new machine, and I have just installed ColdFusion for the first time, and the *very first time* I went into CFAdmin and clicked "Check for Updates" I got that error.

In the console I noticed this:
INFO: Server startup in 38003 ms
Aug 22, 2014 11:50:16 AM Information [http-bio-8500-exec-3] - Initialize file
Aug 22, 2014 11:50:20 AM Information [http-bio-8500-exec-10] - C:\apps\adobe\ColdFusion\11\express\cfusion\logs\application.log initialized
Aug 22, 2014 11:50:20 AM Information [http-bio-8500-exec-10] - Session rotated successfully.
Aug 22, 2014 11:50:20 AM Information [http-bio-8500-exec-10] - Invalid login for Default User
Aug 22, 2014 11:50:22 AM Information [http-bio-8500-exec-10] - Session rotated successfully.
Aug 22, 2014 11:50:22 AM Information [http-bio-8500-exec-10] - C:\apps\adobe\ColdFusion\11\express\cfusion\logs\audit.log initialized
Aug 22, 2014 11:50:22 AM Information [http-bio-8500-exec-10] - User admin logged in.
Aug 22, 2014 11:50:30 AM Warning [http-bio-8500-exec-10] - There was an error while verifying the token. Either the session timed out or un-authenticated access is suspected.

The first "Invalid login for Default User" was me forgetting what the default password is for CF Express (I tried "password", not "admin"), but the second "User admin logged in" was a successful login. And the very next mouseclick I was NOT logged in, it seems.

I think your session rotation is broken.

I also know a lot of other people have been having this.

Pls look into it.


----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3810459

External Customer Info:
External Company:  
External Customer Name: Adam Cameron.
External Customer Email:  
External Test Config: My Hardware and Environment details:


  1. August 22, 2014 00:00:00: 1_Untitled.png
  2. September 12, 2014 00:00:00: 2_cf10-firebug.png


We have tried to verify the bug in the following scenarios: • Making changes in the Server Settings • Creating , Editing & Deleting Databases • Verify all connections in DSN • Enabling & Disabling Sandboxes • Creating & Editing Sandboxes • Making changes wrt RDS • Making changes in the Debugging Properties • Check for Server Updates • With multiple versions of CF installed • CF Full installers as well as Express installers • Fresh install of CF10 & CF11 We are unable to reproduce this bug, unfortunately. If you encounter this issue, let us know and we will reopen this bug
Comment by S P.
11274 | September 04, 2014 12:28:58 AM GMT
My admin area in CF10 is unusable at the moment due to this bug.
Comment by External U.
11275 | September 04, 2014 12:56:20 AM GMT
It's impossible to do anything in the administrator.
Vote by External U.
11304 | September 04, 2014 12:57:00 AM GMT
You not being able to replicate it is not grounds for CLOSING it, it's grounds for you asking for more information. I thought |I actually had followed this up y/day, but the comment seems to have not "taken". En route to work... let me type it in again when I get in front of my PC.
Comment by External U.
11276 | September 04, 2014 01:04:08 AM GMT
@daamsie :Thank you for the prompt reply. The support team will get back to you to resolve this issue over a connect session.
Comment by S P.
11277 | September 04, 2014 01:26:29 AM GMT
Right. Pls reopen this and deal with it like professionals. Just because you can't replicate something doesn't mean it doesn't exist, it means you haven't tried hard enough to replicate it. You could simply be *looking at your code* to see if you have an "aha!" moment where you spot a potential issue, then test that issue. At the very least you should be requesting more information from me. Say like "have a look at your cookies, and [some informed suggestion here]. I'm sure that if you actually attempted to approach this with some vigor, we could get to the bottom of this. An easier way to replicate this is to have multiple CF installs running on the same domain name. Use CFAdmin *to make a change* on one. Then go into CFAdmin on the other and likewise make some change on the second one. This almost always causes it to happen.I hasten to add though that the issue is not limited to same-domain situations. And as per my initial findings here, it doesn't actually necessarily need competing CF instances to mess things up: it can happen with a fresh install. Also, TBH, it all seems vaguely reminiscient of the problems your own sites had with cookies recently: a login to the docs site would completely mess up a login to this site, etc. Obviously those sites are not running CF, but it's perhaps just something you as an organisation have a poor approach with... and the guys that fixed the problem with your sites might have some insight into what you should be looking at. There could be HEAPS of things you could be applying yourself to to work through this, rather than just going [shrug] [clicks close button]. -- Adam
Comment by External U.
11278 | September 04, 2014 02:13:16 AM GMT
We will have the support team reach out to specific users facing this issue.
Comment by Vamseekrishna N.
11279 | September 04, 2014 04:09:02 AM GMT
@daamsie/Adam, can you send us your contact details to cfinstal<AT>adobe<DOT>com
Comment by Anit K.
11280 | September 04, 2014 05:30:03 AM GMT
Vamseekrishna you're making this sound like this is an isolated issue only impacting a coupla people. Can you pls just reopen the bug and treat it appropriately. Dealing with ppl - offline - on an individual basis is not an appropriate way of dealing with this. It's a bug. You need to fix it. Anit: details sent (again. You already have them). But I'd rather we conduct any investigation of this HERE, TBH. -- Adam
Comment by External U.
11281 | September 04, 2014 05:55:52 AM GMT
This happens when I try to save any changes or use the 'Verify All Connections' button
Vote by External U.
11305 | September 04, 2014 05:59:10 AM GMT
+1 - I get this on Verify All Datasources too (among other places) Footnote: I work with Yusuf so probably have the same setup as him (but that doesn't deny we're both having this problem)
Vote by External U.
11306 | September 04, 2014 11:07:16 AM GMT
It's probably worth wading through this very long post by Charlie Arehart about this:
Comment by External U.
11282 | September 05, 2014 08:23:12 PM GMT
I've tried Charlie's suggestions. Cleared all cookies, tried from different machines, different browsers, from the server itself. None of that worked for me. It may well have worked for him, but it's certainly not the only reason this bug happens. I used to get this error in CF9 as well.
Comment by External U.
11283 | September 05, 2014 08:32:29 PM GMT
We understand that you are facing the session rotation issue. We are unable to replicate the issue, irrespective of any environment setup in terms of OS, machines, installation or browser at our end. We are happy to help you, provided, we have a repro case with us. It would be easier for us to debug the issue, if we can have a webex session with any one of the users, facing the issue. In case you are not willing for the same, then at least share the below logs with us, so that we can debug the cause. Charles session ( CF Logs (exception, application, http, server)
Comment by Anit K.
11284 | September 08, 2014 01:11:45 AM GMT
You Adobe guys are a bit flippin' feckless, aren't you? At which point have you asked us: * what values of relevant cookies are * what specific OS we're on, and whether it affects more than one * is it isolated to one machine in particular, or many * which browser(s) I'm seeing this on * which versions of CF I'm seeing it on * if I clear my cookies does that fix the issue, and if so, for how long * what web server I'm using * etc. All the minimum baseline things that ought to occur to your people even before trying to replicate it. No. Instead you just close the issue. Useless. Note I didn't have that list of things prepared, I just thought "what would I be asking me if I actually wanted to solve the issue?", and they came to me whilst typing, all within the space of time it took to type them. And do you know what's worse, Anit? I copied and pasted this from an email to you last week! and you *still* don't bother trying to actually follow it up. I didn't think you were as... um... "motivationally indifferent" as the rest of your team seems to be, but perhaps I'm wrong. The onus is not on us to do your work for you, and come up with a repro case. The onus is on *YOU* to work through it, by engaging your brains and doing an assessment of what could be causing this problem, and then asking us intelligent follow-up question and eliciting information from us which helps your investigation. As this is a transient problem, suggesting webex sessions is a bit dim-witted. Your devs have the code in front of them.. they should be able to ascertain fairly easily what logic would have to occur for us to see what we're seeing. It's not a spaceship guidance system, it's just some shoddily-written cookie management code. As for "irrespective of any environment setup in terms of OS, machines, installation or browser at our end." Please list the OSes, CF install type, CF versions etc you've experimented with. Both for the purposes of elimination of factors, plus - to be frank - I don't believe your people have done at all a thorough job here, so I'd like to see written evidence, with someone's name next to it. -- Adam
Comment by External U.
11285 | September 08, 2014 02:44:15 AM GMT
@Adam, Damsie has already tried it from different machines and browsers, so certainly the issue is not OS or browser specific. Neither, this is related to cookies, as he already tried clearing the cookies. After reading his notes only, we responded, with the logs we need further. As far as, testing at our end is concerned, we have tried it on Win 7/2K8/2K8 R2/RHEL 5.6 & 6.1/Solaris 10 SPARC based/ and the browsers tested are IE/Chrome/Firefox current versions and two version back. Hope this lets you believe, that, Adobe has tried to replicate this issue, before saying "unable to repro". Can you now provide the logs requested below, to expedite the issue?
Comment by Anit K.
11286 | September 08, 2014 03:19:54 AM GMT
It definitely *is* related to cookies, because if one clears the cookies, the problem goes away. For a while. If this is not what daamsie is seeing, I suspect you have more than one problem. The only information going into any logs is what I put in the ticket. All other logs either logged nothing, or not logged nothing relevant at the time the problem occurs. I do not have logs from the last time this affected me available. I'll revisit them next time it does. Am quite keen to hear what you think might be going into the HTTP log which might be relevant to this? -- Adam
Comment by External U.
11287 | September 08, 2014 03:32:58 AM GMT
Oh, something else that is relevant... most often when I see this, it's on CF instance which have no password requirement. That said, it was not the case with the situation I describe above, as I still had the default CF11 Express pwd. However almost always when I experience this, it's on CF instances with no login pwd requirement on CFAdmin. Was this, by any chance, part of your testing? -- Adam
Comment by External U.
11288 | September 08, 2014 03:37:12 AM GMT
That all sounds helping, thanks Adam. On my workstation, I don't use a password for CF Admin. So eventually, this scenario has also been looked upon.
Comment by Anit K.
11289 | September 08, 2014 03:51:09 AM GMT
Yeah, clearing the cookies doesn't do anything for me. So while it may well work for most people it doesn't in my case. Might still have something to do with cookies since I did have to make some changes to server.xml after to get domain cookies working properly with J2EE sessions (separate note: the this.setdomaincookies variable does nothing with J2EE sessions). My config is equivalent to what's below: <Host name=“” appBase="webapps" unpackWARs="true" autoDeploy="false"> <Context path="/" docBase=“{cfusion_home}\wwwroot" sessionCookiePath="/" sessionCookieDomain=“"> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false"/> </Context> Now I think about it - the domain specified here is different to the domain I access CF Admin on , so it would kind of make sense that this setting stuffed something up.
Comment by External U.
11290 | September 08, 2014 05:22:42 AM GMT
@daamsie, Can you try switching “” to localhost and try (CF 10 service restart is required). Alternatively, you can try accessing the admin as and notice the behavior.
Comment by Anit K.
11291 | September 08, 2014 06:09:35 AM GMT
Anit, as this ticket is active, can you please reopen it?
Comment by External U.
11292 | September 09, 2014 02:08:51 AM GMT
Good news. Using the administrator on solves it for me. So I'm pretty convinced that my changes to server.xml caused this issue. I'm not going to go messing with that to confirm though, as this is a live server and I don't really like any more down time than necessary! I do still consider it a bug that it was considered OK to log in to CF Admin and then not be able to do anything. If one operation isn't allowed, then neither should be allowed.
Comment by External U.
11293 | September 09, 2014 02:16:11 AM GMT
I am in the process of documenting a repro case for my situation, which has just recurred. It's definitely cookie-related, so not the same as your issue, dammsie. Stay-tuned.
Comment by External U.
11294 | September 09, 2014 02:18:01 AM GMT
See logs and request/response headers here: Process: * Start CF11 * Browse to http://localhost:8511/CFIDE/administrator/index.cfm * The previous page (Settings) I had been on loads OK * Click "Submit Changes" * On reload I get "There was an error accessing this page. Check logs for more details. " in the middle frame Notes: The cookies passed with the initial main request include these: cfid=dcdc198c-0227-4f7a-8890-a258a9ec33b6; cftoken=0; JSESSIONID=76B79B91644D878D0C8302D5BF9E8B97.cfusion; CFID=705; CFTOKEN=5c688eecb38f760c-7D67311A-B8CD-D746-B5BC61BD38FB2763; CFADMIN_LASTPAGE_ADMIN=%2FCFIDE%2Fadministrator%2Fsettings%2Fserver%5Fsettings%2Ecfm Note there are both CFID and cfid and CFTOKEN and cftoken. With not only different values, but with entirely different types of values. And with the response to that request: Set-Cookie: CFID=706; Expires=Wed, 10-Sep-2014 07:40:31 GMT; Path=/; HttpOnly Set-Cookie: CFTOKEN=e3ce1eee1208bdf3-7D916538-0C82-CF26-E92C55FD9B950EB9; Expires=Wed, 10-Sep-2014 07:40:31 GMT; Path=/; HttpOnly Set-Cookie: CFAUTHORIZATION_cfadmin=; Max-Age=0; Path=/; HttpOnly Set-Cookie: CFAUTHORIZATION_cfadmin="YWRtaW4NY2ZhZG1pbg0xNDEwMjQ4NDMxNDQ3DTg0OEExMkJFQjhERjlDQTY="; Version=1; Path=/; HttpOnly And the request for the main frame sends these cookies: Cookie: cfid=dcdc198c-0227-4f7a-8890-a258a9ec33b6; cftoken=0; JSESSIONID=76B79B91644D878D0C8302D5BF9E8B97.cfusion; CFADMIN_LASTPAGE_ADMIN=%2FCFIDE%2Fadministrator%2Fsettings%2Fserver%5Fsettings%2Ecfm; CFID=706; CFTOKEN=e3ce1eee1208bdf3-7D916538-0C82-CF26-E92C55FD9B950EB9; CFAUTHORIZATION_cfadmin="YWRtaW4NY2ZhZG1pbg0xNDEwMjQ4NDMxNDQ3DTg0OEExMkJFQjhERjlDQTY=" And response: Set-Cookie: CFID=709; Expires=Wed, 10-Sep-2014 07:40:31 GMT; Path=/; HttpOnly Set-Cookie: CFTOKEN=7bf92b5d78b198c6-7D916E41-CEFB-12CE-F4D5E01DD132268A; Expires=Wed, 10-Sep-2014 07:40:31 GMT; Path=/; HttpOnly Set-Cookie: CFADMIN_LASTPAGE_ADMIN=%2FCFIDE%2Fadministrator%2Fsettings%2Fserver%5Fsettings%2Ecfm; Expires=Thu, 09-Oct-2014 07:40:31 GMT; Path=/; HttpOnly That second response seems to be - incorrectly - changing the values of CFID and CFTOKEN. I would GUESS this is because your code incorrectly conflates the cfid & CFID and cftoken & CFTOKEN values together, and gets something that CFAdmin considers is invalid, and does a session rotation. So you need to do two things: 1) find out why you're setting two different cookies for each of CFID/cfid and CFTOKEN/cftoken. Make them the same case throughout. 2) fix your code to be aware that cookies are case sensitive, so cfid and CFID are treated as separate things. And if CFAdmin wasn't encrypted, I could have done the rest of your work for you too and even pointed out where your code is wrong. But I can't so you will have to do a small amount of work for yourselves.
Comment by External U.
11295 | September 09, 2014 02:52:29 AM GMT
Thanks Adam for the details. I am opening this for investigation.
Comment by Rupesh K.
11296 | September 09, 2014 03:07:17 AM GMT
When investigating, bear in mind it's not new to CF11. This happens in CF9 & CF10 as well (so should be fixed in at least CF10 & CF11).
Comment by External U.
11297 | September 09, 2014 03:13:12 AM GMT
AHA! Railo. Railo sets the lowercase cookies. So you don't need to deal with my point (1) below, but you do need to address point (2). That said... this will definitely NOT be what's causing it for Duncan or Yusuf (with whom I work), as they do not run Railo. So there is still some additional dodginess going on as well.
Comment by External U.
11298 | September 09, 2014 05:31:34 AM GMT
Facing a similar issue with CF10 admin on Win7/IIS. See attached screenshot for error description generated by firebug.
Comment by External U.
11299 | September 11, 2014 03:12:22 PM GMT
I was able to fix it apparently. In the \cfusion.ear\cfusion.war\WEB-INF\jrun-web.xml file, had to add: <cookie-config> <active>true</active> <cookie-domain></cookie-domain> </cookie-config> ... this was the only real difference I could tell between those sites which worked and those which didn't.
Comment by External U.
11300 | September 15, 2014 10:39:57 AM GMT
The fix would be available in the next release of ColdFusion. Thanks!
Comment by S P.
11301 | September 28, 2015 03:59:02 AM GMT
Hi Preethi, Did the issue only arise when Railo's lowercased cookies existed? From the moment I started reading this, I wondered if that was the case (I've seen others run into CF Admin issues that ended up being related to Railo's lowercased cookies existing). Thanks!, -Aaron
Comment by Aaron N.
11302 | July 22, 2017 09:12:50 PM GMT
Noting this issue is listed in CF2016's Issues Fixed PDF: (in case anyone cares to verify if it is indeed fixed or not). Thanks!, -Aaron
Comment by Aaron N.
11303 | July 22, 2017 09:18:22 PM GMT