tracker issue : CF-3810459

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.

My admin area in CF10 is unusable at the moment due to this bug.

Comment by External U.

It's impossible to do anything in the administrator.

Vote by External U.

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.

@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.

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.

We will have the support team reach out to specific users facing this issue.

Comment by Vamseekrishna N.

@daamsie/Adam, can you send us your contact details to cfinstal<AT>adobe<DOT>com

Comment by Anit K.

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.

This happens when I try to save any changes or use the 'Verify All Connections' button

Vote by External U.

+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.

It's probably worth wading through this very long post by Charlie Arehart about this: http://www.carehart.org/blog/client/index.cfm/2014/4/10/CF_Admin_error_about_error_accessing_this_page

Comment by External U.

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.

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 (http://www.charlesproxy.com/download/) CF Logs (exception, application, http, server)

Comment by Anit K.

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.

@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.

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.

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.

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.

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=“mydomain.com” appBase="webapps" unpackWARs="true" autoDeploy="false"> <Context path="/" docBase=“{cfusion_home}\wwwroot" sessionCookiePath="/" sessionCookieDomain=“.mydomain.com"> <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.

@daamsie, Can you try switching “mydomain.com” to localhost and try (CF 10 service restart is required). Alternatively, you can try accessing the admin as http://mydomain.com/CFIDE/Administrator/index.cfm and notice the behavior.

Comment by Anit K.

Anit, as this ticket is active, can you please reopen it?

Comment by External U.

Good news. Using the administrator on mydomain.com 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.

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.

See logs and request/response headers here: https://gist.github.com/daccfml/acd24b1b8e307b193fe6 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.

Thanks Adam for the details. I am opening this for investigation.

Comment by Rupesh K.

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.

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.

Facing a similar issue with CF10 admin on Win7/IIS. See attached screenshot for error description generated by firebug.

Comment by External U.

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>.example.com</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.

The fix would be available in the next release of ColdFusion. Thanks!

Comment by S P.

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.

Noting this issue is listed in CF2016's Issues Fixed PDF: https://helpx.adobe.com/content/dam/help/attachments/cf2016-issues-fixed.pdf (in case anyone cares to verify if it is indeed fixed or not). Thanks!, -Aaron

Comment by Aaron N.