Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at CFUNITED 2010 (Landsdown, VA) with: Jay Vanderlyn and Mike Shea

Testing ColdFusion Session Cookie Acceptance

By Ben Nadel on
Tags: ColdFusion

Occassionally, you get random users who cannot seem to hold a session on one of your client sites. The cause of this, most often, is that that user cannot accept cookies either from any site or from the site in question. This is a hard problem to debug over the phone, so to help assuage the problem, I have created a ColdFusion page that tests to see if the user's ColdFusion session information is holding across page calls (which would indicate that their cookies are working as well).

The ColdFusion session testing template works by CFLocating back to itself several times and passing the current session's CFID and CFTOKEN values through the URL as an ID list. After several CFLocation tags, if the user's session is holding, every value in that list should be the same.

  • <!--- Kill extra output. --->
  • <cfsilent>
  •  
  • <!---
  • Param the URL id. This ID will contain a comma
  • delimited list of the CFID / CFTOKEN values.
  • --->
  • <cfparam
  • name="URL.id"
  • type="string"
  • default=""
  • />
  •  
  •  
  • <!---
  • Check to see if the the ID list is less than 5.
  • Technically, 2 values is all we really need to
  • test the cookies, but I like to give it a few
  • extra to see if something really weird is happening.
  • --->
  • <cfif (ListLen( URL.id ) LT 5)>
  •  
  •  
  • <!---
  • Append the currrent session information
  • to the URL id list.
  • --->
  • <cfset URL.id = ListAppend(
  • URL.id,
  • "#SESSION.CFID#-#SESSION.CFTOKEN#"
  • ) />
  •  
  • <!---
  • Relocate back to this page with the updated
  • ID list.
  • --->
  • <cflocation
  • url="#CGI.script_name#?id=#URL.id#"
  • addtoken="false"
  • />
  •  
  • </cfif>
  •  
  •  
  • <!---
  • ASSERT: If we have gotten this far then we know
  • that this page has been called 5 times and that
  • we now have an ID list with 5 items containing
  • this user's session information.
  • --->
  •  
  •  
  • <!---
  • Break the ID list into an array for faster access
  • and easier notation.
  • --->
  • <cfset arrID = ListToArray( URL.id ) />
  •  
  • </cfsilent>
  •  
  •  
  • <cfoutput>
  •  
  • <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  • <html>
  • <head>
  • <title>ColdFusion Session Cookie Test</title>
  •  
  • <style type="text/css">
  •  
  • p.confirm {
  • background-color: ##F9FBFF ;
  • border: 2px solid ##6699FF ;
  • font-size: 28px ;
  • padding: 20px 0px 20px 0px ;
  • text-align: center ;
  • }
  •  
  • </style>
  • </head>
  • <body>
  •  
  • <h2>
  • ColdFusion Session Cookie Test
  • </h2>
  •  
  • <p>
  • In order for you to be able to log into
  • this site, you must have Cookies enabled in
  • your browser. If cookies are enabled, the
  • following 5 values will be identical:
  • </p>
  •  
  •  
  • <ol>
  • <!--- Loop over values and output them. --->
  • <cfloop
  • index="intI"
  • from="1"
  • to="5"
  • step="1">
  •  
  • <li>
  • #arrID[ intI ]#
  • </li>
  •  
  • </cfloop>
  • </ol>
  •  
  •  
  • <p class="confirm">
  •  
  • <strong>Cookies Accepted:</strong>
  •  
  •  
  • <!---
  • We will know that the session cookie
  • information held from request to request
  • if all the values in the list are identical.
  • Check each value against the next.
  • --->
  • #YesNoFormat(
  • (arrID[ 1 ] EQ arrID[ 2 ]) AND
  • (arrID[ 2 ] EQ arrID[ 3 ]) AND
  • (arrID[ 3 ] EQ arrID[ 4 ]) AND
  • (arrID[ 4 ] EQ arrID[ 5 ])
  • )#
  • </p>
  •  
  • <p>
  • If your cookies are not being accepted, please
  • copy and paste the contents of this page into an
  • email and send it to nikki@girls-like-girls.com.
  • </p>
  •  
  •  
  • <!---
  • Output some browser related information that
  • might help the tech team debug just what is
  • going on.
  • --->
  •  
  • <h3>
  • Browser Information
  • </h3>
  •  
  • <p>
  • <strong>User Agent:</strong><br />
  •  
  • #CGI.http_user_agent#
  • </p>
  •  
  • <p>
  • <strong>Request Cookies:</strong><br />
  •  
  • <!---
  • When outputting the browser's cookie, just
  • try to replace out references to CFIDE and
  • ADMINISTRATOR (if they are there) so people
  • don't get any funny ideas.
  • --->
  • #ToString( CGI.http_cookie ).ReplaceAll(
  • "(?i)cfide|administrator|cfadmin",
  • "temp"
  • )#
  • </p>
  •  
  • </body>
  • </html>
  •  
  • </cfoutput>

Hitting the above ColdFusion template, my browser looks like this:


 
 
 

 
ColdFusion Session Cookie Acceptance Testing Template  
 
 
 

Notice that it outputs the CFID and CFTOKEN values. All 5 values should be the same if the SESSION scope was maintained and the cookies were accepted. I assume this will not work for all login set ups, but it will work for most of mine. Additionally, I am outputting the user agent information as well as the cookies that were broadcast by the requesting browser. I figured the more information that the user can email to the tech team, the better.

Now, you have probably seen cookie testing where someone just sets a cookie value using ColdFusion's CFCookie tag and then checks to see if that variable exists in the ColdFusion COOKIE scope. This is not acceptable. CFCookie will always be able to set the value on the first go (as far as I know). What we really need to test is the round-trip journey from the server back to the browser back to the server. This is the only true way to test cookie acceptance (as far as I can see).



Reader Comments

Ben:
Thanks for the excellent writeup!
Amazing timing here as I have been having strange problems lately with some of my applications...
First, I *never* in the past used URLSessionFormat() when building URLs in my session based applications and they always seemed to "just work".
Now I have been doing a bit more CFLocation and other things to move users around between different CF Applications (different application names).
I am now seeing about 1% of my users seem to have problems where their browser will not maintain session correctly. I have it happening on one of my test boxes as well... The boxes have cookies enabled... Restarting, using a different browser Firefox/IE, cleaning all cookies, reinstalling the browsers, praying... nothing seems to fix the problem. I finally decided to "fix it" by modifying my code to use the URLSessionFormat function... That didn't solve my problem.

I am actually having to put the CFID and CFToken into the URLs and links and form submissions myself. It is the only way I have been able to maintain the session on these PCs.

Ever hear of that one? I have been banging my head against the wall for a few days here...

Of course...
I write all that down, and then check the CFQuickDocs link for URLSessionFormat, http://www.cfquickdocs.com/#URLSessionFormat, and I see that there is a comment from tommyviper that states "Using MX7 Ent. on IIS - disabling J2EE caused this function to ignore whether or not the client accepts cookies.".
I am on CFMX7 Standard and I have "Use J2EE session variables" turned off... Is that why the URLSessionFormat isn't working?

Sorry, I don't really know why I am asking you this exactly! lol

Thanks again for all you do for the community, Ben, and I hope you enjoy the 3 day weekend!

@Ken,

To be honest, I have never used ColdFusion's URLSessionFormat(). However, if you are throwing people from one application to another application, they are going to exist in different memory spaces; as a result, I am not sure how they would even hold session information.

Of course, I have never done that, so I could be totally off base there.

Also, I am not aware of the MX7 and IIS interaction, so any comments you get off of CFQuickDocs is going to be better than any I could give you.

Now you have me curious... I need to go play around with throwing people into different apps.

Ben:
I didn't explain that very well.
When I forward the user to a new application, I pass URL variables so that the next app can determine who the user is... usually just a hash of their userid (plus extra text), or using Encrypt/Decrypt...
So once the user gets to the new app, I can see that the first page does exactly what it is supposed to, but when they click a link, or submit a form, the session gets lost and I can absolutely veryify that the users do have cookies enabled.
It has been a nasty little pest...

Ben,
Thanks for this script. I'm using it to diagnose some problems I've been having with one of my websites.

In my case, cookies are written properly to the browser and the browser sends the cookies with the request (per IIS logs) but ColdFusion still can't read them. This results in no shopping cart, no sales, and bad rep.

This only happens intermittently but is a very big problem on such a low volume site as mine. I've detailed my problem on the CF Forums. If you have time, maybe you could take a look?

http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?forumid=1&catid=7&threadid=1308110&enterthread=y

If not, no big deal. I appreciate the time you've taken with your blog. I've been using it as a CF resource for quite some time now.
Thanks!!!
-Sam

@Sam,

Your problem, and cookie problems in general are SO hard to debug especially when you can't duplicate the error in the development environment.

When you say the browser writes the cookies properly, and that ColdFusion is sending them properly, do the users pass the Cookie test page (outlined in this blog post)? Or are they still failing that one?

It's really weird. The site works for most people. The few users that have a problem get my "You must enable cookies to use the site." error message because ColdFusion can't see the cookies. They swear they have cookies enabled and have even sent me screen shots of the cookies in Firefox, IE, Safari, etc.

I've checked my IIS logs and, sure enough, when the user is redirected to my error page, I can see the proper cookies exist in the http request. That is, the cookies are getting to the webserver but not ColdFusion. I've had a couple of these users hit your cookie test page... The page fails but, again, the cookies exist in the user's browser and I can see the cookies in the IIS log file.

Ugh!

I'll keep plugging away and let you know what I find.

I have been "dealing" with this exact behavior for ages. You can pass cfid and cftoken on the url and even set cfid and cftoken in the cookie/session/client scopes on every page till you are blue in the face and for some users cf server simply does not use them and creates new session for every page request.

I have had users go through half an application and suddenly lose their session. From that point on no matter what they do (clear cach, cookies, etc) they will no longer be able to use the application.

In theory the server first checks the cookies and then the url scope for the id and token but even when I can display the passed values on the pages cf still creates new sessions. What gives? I have never found a solution but I know that it is a real problem for many. I have never had to deal with this on any other platform.

Anyone have more to say about this? Any new discoveries since October? We're considering making our ecommerce site available to users that choose to block cookies. I'd love to get any last minute advice before trying to code this. I'll post back here what I discover myself as well.

I've been dealing with the issue of cookie acceptance for awhile, and I haven't been able to come up with a really good solution. I've tested setting cookies on one page and then checking for the existence of them on another, and that works, but there are usability problems with that approach.

I really appreciate the ideas in this post. It offers a creative way to check if cookies are enabled in a browser. I am, however, having issues using this method with IE 7. It seems that IE 7 will keep the cfid and cftoken values the same for each iteration even when cookies are disabled.

Is there an update to this method that will work with IE 7? Is there another method for testing cookie acceptance?

@David,

If IE 7 keeps the same CFID / CFTOKEN values, then that should mean that it is maintaining the session? I am surprised that works if cookies are disabled. Maybe it still keeps "session cookies" which will be deleted when the browser closes.

Actually, what I'm finding is that IE 7 will keep the same CFID and CFTOKEN values but will not maintain the session. It's odd, I know. I will disable cookies in IE 7 and then run the code you have here and it will tell me that cookies are enabled and will show the CFID/CFTOKEN values to all be the same. But then when I try logging in on my Web site, the site will not maintain a session.

My browser is set to block all cookies, and I've looked in the Temporary Internet Files folder and the Cookies folder on my C: drive, and I don't see any cookies anywhere (although I'm not sure where to look for "session cookies").

Any ideas?

Thanks,
David

I'm sorry, I forgot to post an update to my situation (glad I subscribed to the comments here).

In my case, it turned out ColdFusion was doing exactly what it was supposed to do (Ben's script confirmed this).

The webserver was setup to host two different domains, a .com and a .co.uk. Both domains pointed to the same webroot and shared the same IIS log. It turned out that there was a JavaScript redirect during the checkout process that we didn't catch. (We inherited this app and don't use Javascript redirects so didn't think to look for it.) The .co.uk user was redirected to the .com address and the CFID/CFTOKEN values were not passed so the session was lost.

Because both domains used one IIS website, there was only one logfile and the the log didn't indicate which domain was used.

Very frustrating but I'm glad it was a coding problem and not related to browsers and/or ColdFusion.

Thanks again Ben for this great resource. Keep up the good work.
-Sam

I also having the same "session lost" issue on one of my project. When an user login, couple of session variables are set and then user is redirected to his profile page. This works perfectly for most of the users but fails for some minor users. CF just creates a new session (a new cfid & cftoken) when user arrives his profile page rather than using the existing one.

I don't think my problem is due to cookie being turned off as it happened once on our development box and we never able to recreate it since then. I have never have this problem with my other projects during my 5 years of CF development life.

I then found this Adboe article:
http://kb2.adobe.com/cps/181/tn_18171.html
Basically it says setting session variables while doing cflocation may results in cookie not properly set. I tried using client redirection after user login to send him to his profile page but still have no luck.

@Tomy,

I believe that the cookie / CFLocation issue was in older versions of ColdFusion. I am pretty sure that as of MX (at least 7) this has been fixed. As such, I am pretty sure that is not the issue.

Can you get a given user to replicate this issue? Or does it happen completely sporadically?

I feel everyone's pain.

In my case for an extremely small number of users session state is lost during a https post to the same page. This occurs well after the user is logged in on https, and only when posting to the same page. No tricky redirects here.

It was impossible to debug until it happened to client of mine. I went thru all the usual environment testing with him to no avail. Then I had him disable his anti-virus software and problem solved. Of course his anti-virus software was actually a suite of software with all its "I'm going to protect you from yourself" applications.

I had him change anti-virus companies and he's never had another experience of that issue. Of course you can't expect users to do that, nor would you want the liability.

My solution? In this case I don't worry about it. I figure as diverse as user environments are I can't expect 100% usability. I'll settle for 99.9%.

Kinda reminds me of the problem I experienced with users stepping on each others sessions, which I finally tracked down to their network switch not maintaining sessions properly, but that's another story.

@Phil,

Yeah, I've heard of anti-virus apps causing problems. Sometimes they just go overboard. In that case, I think some times adding the site to the "trusted sites" in internet options helps fix it.

I have a weird issue where just a couple of users can't seem to read cookies. Session is maintained fine, so cfid/cftoken are working. But I set another cookie to note that certain files have been installed on the particular computer. On just a couple of computers, strangely it's mine and another developer's, cf can't seem to read additional cookies that are set. I can look in the cookies directory and see the cookie values are there, but for whatever reason cfmx7 isn't reading them. I dumped the cookie scope at the end of the page and cfid/cftoken show, but that's it.

Any idea what could be causing cfmx7 to not be able to read a client's cookies? Especially on a developer's machine?

Thanks!

Ken

@Ken,

On the computers that are able to reproduce this behavior, does it work the same on the different browsers (ex. IE and FireFox). If not, if one works and the other doesn't then it maybe at the browser level.

I recently had a problem in which some code was accidentally switching domains after a particular action - adding the "www":

somedomain.com

... to:

www.somedomain.com

This worked fine in FireFox because it sent Only the appropriate cookies; however in IE, both the non-www AND the www subdomain cookies were being sent (an error in IE's cookie functionality as far as I could figure out).

Not saying that's your problem - just that you should check cross-browser to see if the various browsers all reproduce the problem.

Good thought, it is browser specific. However there is no "www" in this case or anything like that. It is an internal domain so it is just http://applicationname/index.cfm. Furthermore I am looking at the cookies in the cookies directory and it is listed as "userid@applicationName[1].txt". The [1] seems to be fairly normal behavior because I see it for a lot of cookies in the directory.

Presumably developers have more updated versions of IE and that is why this is occurring for us only, that is what I presume without real evidence. So when everyone gets upgraded my life will become hell until I figure out the issue. Either that or it has something to do with us having IIS (for .NET development) and other such no-no's installed locally.

Well, if you have any more ideas they'd be greatly appreciated. I'll continue to pursue it from a browser level.

Have a good one..

Ken

Ken, a while back I had a cookie issue that was giving me fits and seemed to be localized to my development machine. I can't remember the details but I finally figured out is was specific to IE and was occurring when debugging was enabled. In this case I was using IP specific debugging.

I never did figure out why it was happening, but now every time I have strange behavior coming from IE I turn off debugging to see if the problem goes away.

Just a thought.

@Ken,

Sorry, I don't have any more ideas. The only other thing I can think of is that the cookie is being set twice with slightly different settings that, for one reason or another, are not being seen as the same cookie (which is causing double posting)... other than that, I got nothing.

Ken, I am having the same issues with sub domain cookies not being seen on certain computers. Did you ever figure out what your issue was?

Most of the computers test will read the cookie on the CF server just fine that was set on www.ncsl(.net site) and read it on ecom.ncsl(cf site reading .net cookie). The computers that don't see the cookies are all major browsers besides Firefox which still works. Such a pain.

@Ken,

Have you already worked around the issue that CF cookies are not case-sensitive, while other cookies (such as JS cookies - I don't know about .Net cookies) are? For example, if you create a cookie called "CamelCaseCookie" in CF, CF actually creates the cookie in all-uppercase, as you will see if you look at the cookies on your computer:

<cfcookie name="CamelCaseCookie" ... />

Now if you want to see that cookie in JS, you have to look for CAMELCASECOOKIE since JS cookies are case-sensitive (or at least they are in the browsers with which I'm most familiar).

Similarly, I wonder if it isn't necessary to create cookies in all-uppercase with other apps so that CF can read them back in?

I don't know if this applies to what you're doing at all, but I just thought I would throw it out there in case it does. My group has been burned a couple of times with this issue.

DCS, This error is only occurring on a few computers.

So example:
Computer 1-IE7,FF3.5
Computer 2-IE7,FF3.5

On Computer 1 Both browser are working where the main website (.net site) sets the cookie and the sub-domain (cold fusion site) is able to read the cookie.

On Computer 2 Only Firefox is working. I have a bunch of other browsers installed for testing like Safari and Opera they also don't work.

So in my mind something is installed on the computer preventing the cookies to transfer from main website to the sub-domain. I think the numbers are very small for the non working computers or we would be getting a lot more calls about it. Just a pain that I can explain what is going on.

@Dcs,

I was not aware that cookies were made to be uppercase by ColdFusion. That makes sense though (from a consistency standpoint) - they make pretty much all struct keys uppercase.

Exactly. But it would only matter if you're also developing in (for example) JavaScript or a third-party tool that uses JavaScript. We ran into the issue with an ad server - we wanted the ad server to test for the existence of a cookie created in ColdFusion. We couldn't figure it out until we actually checked the browser to see what cookies were actually being created.

@Dcs,

Yeah, the case-insensitivity is also something that we've seen trouble with in AJAX related code as well (all struct keys being serialized in UPPER case).

I've got you all topped! Try session cross linking! This my story, gripe session, and question about a possible work around. No real useful information below:

Back in CF 5, we had an app (contest app) where user A would suddenly see user B's profile page. Session were becoming cross linked!!!!! We switched servers, I did every debugging trick in the book, including turning off cookies. It was a total fricking nightmare.

Finally, in utter desparation, I wrote my own encrypted session string that got passed around on EVERY url, and we abandoned using session variables altogether. That was 5 years ago.

The complaint from some users is the long, weird looking url string: "session=0QDP]%3A%2BA%3D*"%2F>Q1_^L%3F%25NZ" (DESEDE encryption)

Now, with a total rewrite underway, we're going with a front controller scheme with clean urls. I wanted to go back to using session variables, but after reading this thread, I'm scared as hell at doing so. Mostly because I'm the one that gets to troubleshoot with the one in a thousand user that can't use the app (serious prizes are involved. People won't just go away and leave me alone!)

Reading this thread, I just can't buy Ben's comment that MX 7 solved the old problems. What the hell is wrong with Coldfusion? I never hear of this problem with my ASP.NET apps!

Has anyone bypassed CF to read the HTTP header directly? Is there some call out to java or some such that an app could use here?

OK. I poked around and with some help from Ben's exploits with GetPageContext():

http://www.bennadel.com/blog/758-ColdFusion-GetPageContext-Massive-Exploration.htm

I was able to tease out the raw HttpServletRequest. In the url above, I noticed getFusionContext().getCurrent. A cfdump of this guy shows a request field. A cfdump of that shows it as a jrun.servlet.ForwardRequest object. Cruising the docs for that object:

http://www.adobe.com/livedocs/jrun/4/javadocs/jrun/servlet/ForwardRequest.html#getServletName%28%29

showed that it is a subclass of jrun.servlet.RequestWrapper. Clicking the link for that in the link above shows the magic getCookies() function. So, here is the code to look at the cook from the raw HttpServletRequest as reported by java?:

<cfscript>
test = GetPageContext().getFusionContext().getCurrent().request.getHttpRequest().getCookies();
for (i=1; i LT arraylen(test); i=i+1) {

writeoutput(test[i].getName() & "<br/>");
writeoutput(test[i].getValue() & "<br/>");
writeoutput("<br/><br/>");
}
</cfscript>

If anyone can reproduce the lost session problem on a consistent basis, you you run this code on a page that lost the session and tell us if the cookie is really there and CF is just tweaking out? Or do we have to start looking at the webserver<-->jrun junction for a solution?

Sean

Sorry, here is a less buggy version:

<cfscript>
if (isdefined("url.dumpcookies")) {
// Get at the cookies in the lowest level way possible
test = GetPageContext().getFusionContext().getCurrent().request.getHttpRequest().getCookies();
if (isdefined("test")) {
writeoutput("<div style=""clear:both""><br/><br/><hr></div><br/>COOKIES:<br/><br/>");
for (i=1; i LTE arraylen(test); i=i+1)
writeoutput("NAME: " & test[i].getName() & "<br/>VALUE:" & test[i].getValue() & "<br/><br/>");
}
}
</cfscript>

@Sean,

Sounds like you had some bad luck with your sessions. I'll be honest with you - I haven't had much of any problems with session, other than the occasional undefined session variable (which I think I narrowed down to async requests). I'm on CF8 now, soon to be on CF9 and I'm feeling good about it.

I'm having some cookie trouble with CF9. I have the multi-server version installed on XP. I'm trying to have my cookies set to the domain with no luck. I have this.setDomainCookies = true; in my Application.cfc. When I hit my page, the cookies are still set to www.mydomain.com instead of .mydomain.com. Our production servers (on CF8) handle domain cookies properly. It's only my development on CF9 that is having issues.

Any ideas?

I don't have any insight into why it might be happening but have you tried using CFCOOKIE to set the cookies manually for the entire domain? Maybe you could put tags to do that in onSessionStart()?

<cfcookie name="cfid" value="#session.cfid#" domain=".mydomain.com" />
<cfcookie name="cftoken" value="#session.cftoken#" domain=".mydomain.com" />

The comments in the following link appear to be relevant - it looks like it might be a browser issue?
http://www.jensbits.com/2009/07/29/coldfusion-dropping-losing-or-resetting-session-variables-and-cfidcftoken/

@Joel,

I'm not that great with domain-specific cookies; never really dealt with them explicitly. I have seen cases where some browsers work and some don't (but I think that was an IE bug a while back). Take a look at the link @DCS posted.

I tried the onSessionStart with manually setting the cookies. I end up getting duplicate cookies. One with www.mydomain.com and the other with .mydomain.com.

Any other ideas?

@Joel,

You could try manually expiring the cookies on www.mydomain.com before setting them for .mydomain.com.

@Joel,

This could be as a result of how you have your DNS entries set up for the domain. Is www an alias to the server's IP address or do you have a separate A record pointing to that IP address? If you have an A record, get rid of it and just use an alias.

On the server, check nslookup to see what domain is returned first when you enter in the IP address. I'm assuming the first domain returned by the DNS resolver on the server machine will be what Cold Fusion uses for the domain cookie name.

I've been on and off trouble shooting this for a client now for quite a while. Thanks to these comments I think I narrowed down the issue to where a few people were starting by going to http://domain.com and logging in. At one point in the application menu system, the menu links aim to http://www.domain.com - as soon as they hit that the IE8 users lose their logged in session.

@Steve,

Oh yeah - switching to another sub-domain will definitely trip you up from time to time. Glad that you got some value out of these comments.

I'm having a miserable experience regarding session management in an online store and I'm hoping someone might have some input that will help.

When switching from the non ssl catalog and cart page to the ssl page for checkout the session id changes. I'm passing the cfid and token in the url but cf and/or apache grabs a new session id when the domain switch happens.

Recently I upgraded my web server running cf7 with apache on linux to a new server running cf9 with apache and still on linux. Before the server change it has worked great for 3+ years.

The stores are using a shared ssl certificate on a different domain but on the same server. If I use a secure address on the same domain name it works fine. The problem is that I don't want to have to buy a separate secure cert for each online store that I host. Right now there are 5.

To see an example go to shop.aldercreek.com. Add something to the cart and the proceed to checkout. If you get a login screen it worked. If you get a cart empty message, it didn't. Most of the time I get a cart empty message.

-Has something changed from cf7 to cf9 in how cf handles sessions?
-Does anyone else use a shared ssl cert and if so have you seen this problem?
-Is this a software problem on the server?
-Sessions can and should stay persistent across different domains correct?

The folks at hosting.com/hostmysite.com insist that it's a coding issue but I don't buy it.

@Brad,

I just tried it in Google Chrome and it seemed to work out ok (I don't see any empty cart - I am prompted with the ability to create an account or login). I get the same in Firefox as well. Do you have to be already logged-in for the error to happen?

I'll be honest with you - I've never had to maintain session across domains before. But, as long as you're on the same codebase and you pass the CFID/CFTOKEN across, I can't see why a new session would kick up (seeing as ColdFusion doesn't care what domain you're on as long as the tokens are available.... it's usually the cookies that cause the session problems).

Has anyone noticed an issue where sometimes two(2) CFID and CFTOKEN cookies are set in IE8 and IE9?
They have identical values, but Coldfusion does not recognize the session, and resets both on refresh.
Thanks,
Jill

If I set in application.cfc (CF 8)

this.sessionmanagement = true;
this.setClientCookies = false;

I am losing my sessions

Where as if I do

this.sessionmanagement = true;
this.setClientCookies = true;

I maintain my sessions.

************************************************

Now both the above code works on other machine, and session holds (CF 8).

Unable to figure out why? Any clues?

CF9 ---

Losing session:

Application.cfc

  • this.sessionmanagement = true;
  • this.setClientCookies = false;

I load a Login page, authenticate the user name and password. Once authenticated, I take them to secure website else throw them back to Login page.

The above code maintains session as long as the page does not have cflocation tag.

I lose session if I have a

  • <cflocation addtoken="no" url="index.cfm">

When I do the dump, my session variables get new CFID & CFTOKEN, it does not maintain session.

This is happening on just 1 machine and is recurring. I take the same code with same CF setup and it works on other CF app server.

If I change the code to below code, the session maintains. And the reason is because the cookies are being accessed and is used for session.

  • this.sessionmanagement = true;
  • this.setClientCookies = true;

My Question is why does the first one not work on some machine?

  • <cflocation addtoken="no" url="index.cfm">

I'm having the issue as others are, but only on a couple of my sites, and just recently.

This leads me to believe my host (Hosting.com) has changed a setting on a (shared) ColdFusion server, as code that worked fine for years suddenly has stopped working... even when using the same computer and same browser that it worked on in the past.

I have the following in my application.cfm:

  • sessionmanagement="Yes"
  • SetClientCookies="Yes"

If I do not add cfid/token to each and every redirect (be it cflocation, javascript, form submission, hyperlink etc.) the session is lost.

Subdomains are not the cause in my case as I verified using Ben's code, and cookies were not holding. I'm using IE9 and the sites in question are on ColdFusion 8.

On my virtual private server accounts, I use J2EE session variables, and have never had this issue, but the effected accounts are on shared servers.

I have contacted my hosing company asking if any server settings had been changed, and gotten no reply.

It seems that this issue has been going on for a long time, and I'm surprised there's still no resolution.

This may or may not be related to a problem I just stumbled into. I recently moved my production site from a Windows/Apache/CF server to a Linux/Apache/Railo server. Everything seems fine except that IE suddenly won't maintain sessions.

I was looking all over the place for differences between the environments but getting nowhere. In desperation I tried my old Windows/CF server - same thing!

In my environment the IE configuration is locked down hard & administered remotely (not by me) so it seems that something has changed in IE.

Looking a bit closer I can see that IE is blocking cookies from this site in both environments.

I have also read elsewhere that IE blocks cookies from sites that do not have a compact privacy policy. So far my attempts to install a compact privacy policy haven't changed anything.

Does anyone have any more insight into this?

Follow-up - I should have mentioned that FireFox and Chrome have no problems maintaining session on either server. This seems to be purely an IE8 thing.

We are having the same problem with many of the shoppingcart websites we designed and host. The problem does seem to be isolated to IE 8 and I will check out the compact privacy policy. Our experience so far is that clearing the browsers cookies has fixed the problem every time, at least temporarily. On our machines here, the fix can last as little as 3 hours before the session is lost again.

We're having a problem with CF sessions and Google Chrome. Diagnosing it using your test code, we have found the following:

With a normal, cookies-enabled Chrome instance, the Ben Nadel Test (as we're calling it) FAILS: it says "cookies accepted: no", and the five token values are different. (But a simple cookie test it says it accepts cookies.)

Pop open an "incognito" window, not changing any settings otherwise, and run the selfsame Ben Nadel Test, and it works: "cookies accepted: yes", all five tokens the same.

This makes no sense to us. How can it fail with cookies enabled, but then work in incognito? Moreover, just what is wrong with Chrome outside incognito mode? It's seriously screwing up anything we write using sessions. We can't just check for cookies, because Chrome in both instances accepts cookies. I'm at this point thinking of modifying the Ben Nadel Test and running that each time to figure out if you're on Chrome and Chrome is misbehaving and asking you to go into Incognito mode if it is...

Has anyone experienced anything like this with Chrome? It doesn't always happen on every copy of Chrome, but once it starts happening, it continues like I describe above. Basically, WTF?

@Karl,
I have never had an issue with chrome not accepting cookies. Just wanted to point out that it is normal for the incognito browser to accept cookies. They are just deleted as soon as you close the browser.

I wonder if some kind of chrome extension could be killing the cookies. Have you tried monitoring with fiddler to see what's getting passed back and forth?

@lee,

Yeah, I know -- what's bugging me is that ColdFusion session variables don't work for us sometimes in Chrome, but they do suddenly start working when you go into an incognito session.

Simple minded cookie tests make it seem as if Chrome is accepting cookies, but when you run the Ben Nadel Test, that's when you find out Chrome is not really accepting cookies, or doing something weird to them so that it doesn't keep a CF session and fails the Ben Nadel test.

What's really weird is that then you turn on incognito, and whatever it was doing that messed it up and failed the Ben Nadel test stops happening and it passes the test, and keeps CF sessions...

I'll look into Fiddler and see if that might help me; thanks for the tip.

Meanwhile, have you tried the above code from Ben? We find that on fresh installs of Chrome, the test passes, but use Chrome for a while (non-icognito, nothing special, accepting cookies, etc.), and after a while, go back and try the Ben Nadel Test and it fails. This is the behavior that has us scratching our heads...

So I finally figured out what's going on.

Turns out we're running FinalSite, which does its own CF things. One of the things it's doing is setting CFTOKEN and CFID. Wrongly. Instead of only setting them in www.domain.com, (or even just domain.com), it ALSO sets .domain.com (note the starting period).

So that royally screws things up in Chrome (and also Firefox; Opera seems smart enough (or wrong enough) to ignore the starting period). If we have an app at site1.domain.com, and it sets CFID and CFTOKEN at site1.domain.com, IT ALSO SEES THE CFID and CFTOKEN from .domain.com (in Chrome and Firefox)! Hence the loss of session, hence the whole confusion.

So, we're sending a trouble ticket to FinalSite, hoping they will fix it. Meanwhile, it's at least sanity-restoring to finally know what the heck was happening!

I am currently still experiencing this dumb issue (2013) with CF9. The problem I've seen is specific to IE. The problem is not that cookies are not set...it is that every now and then (and I agree, seems very random, so extremely hard to debug) the cookies are set twice. whend I dump the 'cookie' scope, I see that there is TWO instances of both CFID and CFTOKEN. When this is the case, if I try to login to my site, it will technically succeed...but the page will refresh and act as though login failed...the issue is it seems like the session info is not being retained.

In order to make the browser login again, the only thing I have been able to do successfully is to go to Tools->internet options->General tab->Browsing History Settings->View Temporary Internet files. I simply select all files and wipe them all out. Essentially, all you need to do is clear your cookies...but sometimes that's a little tricky...this method describe above works every time!

Anywa, once you clear all cookie info...if you dump the cookies scope, you notice that the is only a single pair of CFID and CFTOKEN values. Once that is the case, is all works as expected.

Of course, most users will not know to do that, so it's a problem you need to deal with youself. Oddly enough, even knowing all this...I'm still having difficulty clearing out the cookies programmatically...anybody know any easy tricks that work?

I tried to this code:

  • <cfoutput>
  • #request.utilsobj.dump(cookie)#
  • <cfset intCFIDE_Counter = 0>
  • <cfloop collection="#cookie#" item="k">
  • <cfif k eq "CFID">
  • <cfset intCFIDE_Counter = intCFIDE_Counter + 1>
  • </cfif>
  • </cfloop>
  • <div style="color:red; font-size:50px ">
  • #intCFIDE_Counter#
  • </div>
  • <cfif intCFIDE_Counter gt 1>
  • CLEARING...
  • <cfset StructClear(session)>
  • </cfif>
  • </cfoutput>

but for some reason, StructgClear() seems to not do the trick. Any ideas.

Hope this description helps somebody out there and I hope somebody can help me.

@victor - This is how I fixed the login problems with CF9 (including the double cfid & cftokens). Put somewhere in your login page, this code should "correct" all the potential problems. Let me know if it helps you.

<!--- it's possible for a .mydomain.com cookie to interfere with the subd.mydomain.com cookie --->
<!--- so check for possible problem and then clear the mydomain cookie before attempting to login --->
<!--- (also reset the subd.mydomain.com cookie as it could be it's own problem) --->
<cfif session.userID IS 0> <!--- if not yet logged in (as would be expected of course) --->

<cfif isDefined("Cookie")>
<cfset idCount = tokenCount = 0>
<!--- Coldfusion (9 at least) can somehow have two CFIDs and two CFTOKENs in Cookie which will --->
<!--- cause a login problem that apparently isn't correctable without clearing the Cookie struct --->
<cfloop collection="#cookie#" item="v">
<cfif v IS "CFID">
<cfset idCount += 1>
<cfelseif v IS "CFTOKEN">
<cfset tokenCount += 1>
</cfif>
</cfloop>
<cfif idCount NEQ tokenCount OR idCount GT 1>
<cfloop collection="#cookie#" item="v">
<cfset structDelete(cookie,v)>
</cfloop>
<cfif isDefined("session.cfid")>
<cfcookie name="cfid" value="#session.cfid#" domain=".mydomain.com" expires="now">
<cfcookie name="cfid" value="#session.cfid#"><!---subd.mydomain.com session only--->
</cfif>
<cfif isDefined("session.cftoken")>
<cfcookie name="cftoken" value="#session.cftoken#" domain=".mydomain.com" expires="now">
<cfcookie name="cftoken" value="#session.cftoken#"><!---subd.mydomain.com session only--->
</cfif>
<cfelse>
<cfif isDefined("cookie.cfid") AND isDefined("session.cfid") AND cookie.cfid IS NOT session.cfid>
<cfcookie name="cfid" value="#session.cfid#" domain=".mydomain.com" expires="now">
<cfcookie name="cfid" value="#session.cfid#"><!---subd.mydomain.com session only--->
</cfif>
<cfif isDefined("cookie.cftoken") AND isDefined("session.cftoken") AND cookie.cftoken IS NOT session.cftoken>
<cfcookie name="cftoken" value="#session.cftoken#" domain=".mydomain.com" expires="now">
<cfcookie name="cftoken" value="#session.cftoken#"><!---subd.mydomain.com session only--->
</cfif>
</cfif>
</cfif>
</cfif>

Let me try that again with the code tag.

  • <!--- it's possible for a .mydomain.com cookie to interfere with the subd.mydomain.com cookie --->
  • <!--- so check for possible problem and then clear the mydomain cookie before attempting to login --->
  • <!--- (also reset the subd.mydomain.com cookie as it could be it's own problem) --->
  • <cfif session.userID IS 0> <!--- if not yet logged in (as would be expected of course) --->
  •  
  • <cfif isDefined("Cookie")>
  • <cfset idCount = tokenCount = 0>
  • <!--- Coldfusion (9 at least) can somehow have two CFIDs and two CFTOKENs in Cookie which will --->
  • <!--- cause a login problem that apparently isn't correctable without clearing the Cookie struct --->
  • <cfloop collection="#cookie#" item="v">
  • <cfif v IS "CFID">
  • <cfset idCount += 1>
  • <cfelseif v IS "CFTOKEN">
  • <cfset tokenCount += 1>
  • </cfif>
  • </cfloop>
  • <cfif idCount NEQ tokenCount OR idCount GT 1>
  • <cfloop collection="#cookie#" item="v">
  • <cfset structDelete(cookie,v)>
  • </cfloop>
  • <cfif isDefined("session.cfid")>
  • <cfcookie name="cfid" value="#session.cfid#" domain=".mydomain.com" expires="now">
  • <cfcookie name="cfid" value="#session.cfid#"><!---subd.mydomain.com session only--->
  • </cfif>
  • <cfif isDefined("session.cftoken")>
  • <cfcookie name="cftoken" value="#session.cftoken#" domain=".mydomain.com" expires="now">
  • <cfcookie name="cftoken" value="#session.cftoken#"><!---subd.mydomain.com session only--->
  • </cfif>
  • <cfelse>
  • <cfif isDefined("cookie.cfid") AND isDefined("session.cfid") AND cookie.cfid IS NOT session.cfid>
  • <cfcookie name="cfid" value="#session.cfid#" domain=".mydomain.com" expires="now">
  • <cfcookie name="cfid" value="#session.cfid#"><!---subd.mydomain.com session only--->
  • </cfif>
  • <cfif isDefined("cookie.cftoken") AND isDefined("session.cftoken") AND cookie.cftoken IS NOT session.cftoken>
  • <cfcookie name="cftoken" value="#session.cftoken#" domain=".mydomain.com" expires="now">
  • <cfcookie name="cftoken" value="#session.cftoken#"><!---subd.mydomain.com session only--->
  • </cfif>
  • </cfif>
  • </cfif>
  • </cfif>

Thanks Gary...I put the code in place.

I replaced the .mydomain.com with .pixel34.com and also changed the initial check to see if the person was logged in or not to match my setup.

I'll test it out...but I'll only be able to tell if it did not work...else, I'll be waiting for awhile :)

Thansk for your reply and providing the code!!!

Gary,

I can definitely confirm that your code works. AS it turns out, it did happen again...and upon examining the code I modified from your post, I realized that I had missed one instance where I neglected to change the place holder: '.mydomain.com' such that now, I was getting a single CFID value, but two CFTOKEN entries in the cookies scope. After I fixed that,the issue went away without me having to clear cookies manually.

And by the way, the behavior does seem to be related to the reuse of CFID/CFTOKEN values even after a session has expired:

as described here in a similar post: http://www.bennadel.com/blog/1537-The-Same-CFID-CFTOKEN-Values-Are-Used-Across-ColdFusion-Session-Timeouts.htm

Anyway, thanks again for your code!!!

@victor

Thank you for the update. I'm glad you got it working and found the mods you needed.

I should have mentioned that I don't know if using cflogin helps or makes these problem worse and we do not use cflogin. And after I discovered the double cfid's and cftoken's and put in my fix, I never knew for sure if it happened again. I didn't think it was IE that was doing it at the time but I guess it could have been. But after the fixes, we haven't had one complaint about logging-in that could be connected to cookies and we have many thousands of daily users.

One difference between using the jsession ID and cfid/cftoken had been that a new jesssionID was always created for new sessions whereas the cfid/cfoken was not. I read a blog (I forget whose) where it was found that apparently for CF9 (or one of its security hotfixes), cfid/cftoken were recreated for new sessions. I have not seen this reported elsewhere. Also, I believe one of the CF9 fixes added the httponly attribute for cookie. So Adobe upped up security for CF9 but it broke some things and left a lot of people scrambling. Well that's my take on it anyway.

Having problems with cookies. Was doing it the way you mentioned. Creating the cookie using cfcookie then checking to see if that variable exists to track the user. My problem is if the session expires a new cookie is created. I used your script and the comments to diagnose the issue. Thanks for the info and excellent write-up! **nikki@girls-like-girls.com.. um yea**