Sounds like you’re also bumping into a session timeout? You may need longer than 20-30 minutes. You can define this in the server or per app (in the Application.cfm/cfc).

If you were using Application.cfc (which, is better / more preferred), You may want to make sure you’re using “this.SetDomainCookies = true;”

Very good explanation of Application.cfc by Ben Nadel:
http://www.bennadel.com/blog/726-ColdFusion-Application-cfc-Tutorial-And-Application-cfc-Reference.htm

@Todd
The session timeout is set to 8 hours; no problem there. SetDomainCookies did not work. I tried it.

And, I did see Ben’s post. I had read it quite some time ago. Regarding setDomainCookies he says in that post:

A boolean flag to determine if the CFID and CFTOKEN values are set for domain and not just a host value. This defaults to false. I have never used this and so I am not exactly sure what this means.

Can you post your cookie code by any chance or are you just using this.setClientCookies= true;

Anyway, your blog post is right. The moment you get a new CFID/CFTOKEN, you basically have a new session at that point. There can be several reasons why the person got a new one: cookie tampering, switching browsers mid-session, ISP hiccup (new ip assignment took longer than normal, etc).

In fact, if you ever enable “Use J2EE session variables” in the CFAdmin, you’ll get a new session every time you close the browser.

@Todd

This is an application I inherited at work. It uses an Application.cfm and is set up according to this Adobe TechNote: http://kb2.adobe.com/cps/179/tn_17915.html

If I did not build it and it is working, I don’t change it over to application.cfc. The guy who built it sits next to me. Not very neighborly to rewrite his work.

So, to answer your question: setClientCookies=”no”

Bear in mind, this application worked for several years then pooped out all of the sudden. But just for some people and not for others.

Now the Application.cfm ensures that the domain name is consistent across the application. No more issues have occurred.

The joys of code inheritance.

I experienced similar issue with app that had setClientCookies= true. It was not inherited app, it was app I wrote and it started to happen after I added few more input fields.

Long story short – I found out that there is limit of how many cookies browser can handle per web-site/page and my app happen to leap over that limit after I added couple more fields to it.

I was storing input field values in cookies to be retrieved and input fields pre-filled when user returns back to page. App had about 45 cookies before last few were added. Then I added few more input fields resulting in few more cookies and all in sudden session variables started to disappear. What I noticed app did not drop session variables until cookies got saved via CFCOOKIE – up to that point app was working fine.

This leads me to believe that my app reached limit of how many cookies are allowed per site and once that limit is reached browser ether:
- destroys all cookies from browser memory
- uses FIFO queue for storing cookies and pushes out oldest cookies – which are CFID and CFTOKEN for CF apps – from memory when cookie limit is reached

Ether way – cookies CFID and CFTOKEN could not be found prompting CF server to initiate new session. It did not matter if I tested using IE or FF – same result.

I revised my cookie policy afterwords by combining them into 4 cookies per page.

I did not do extensive research however I could not found any references that would explain how many cookies are allowed per site. I did find vague reference that size of the cookie should not exceed 4K. App I am working on now is safe for now since I’d have to triple the number of input fields to reach that limit.

This is different issue and different solution from described above however both issues and solutions are very close cousins.

If I may add unrelated comment then I somewhat disagree with statement ‘Actually, this is not ColdFusion’s fault; it is a browser issue…’. It’s almost the same as saying there is no difference between George W. Bush Sr. and George W. Bush Jr.

@Egils

Thanks for sharing the cookie limit. You’re right; these issues are close cousins.

However, I still believe my issue was not ColdFusion’s fault. While researching this, I found developers with the same issue in other languages.

Hi Jen,

Did you ever figure out why the session variables were dropping?

@Shawn

Yes, it was the ‘www’ difference between mysite.com and http://www.mysite.com. The domains were considered two different sites by the browser and CF reset the CFID/CFTOKEN.

Interesting. I’m currently having the same problem, no rhyme or reason to it…it’s like the server is saying for the next hour and a half this particular variable is not going to stick. Anyway, my app is using a lot of includes with relative paths (as opposed to the full http:// url). Have you run across anything related to relative paths that might cause the problem?

@Shawn

No, relative paths didn’t seem to be the issue. It boiled down to ensuring that the domain was immediately changed to include the www (and to keep it that way) before any session vars were set.

I said above in the comments that I now ensure that the application.cfm changes the domain name; however, as an added measure and since I already had it in place, I wrote a RewriteRule in my httpd.conf that now rewrites the URL to include the www.

Like you I found it bizarre, inconsistent, and bewildering.

One other thing to note…Recently I have had trouble with IE caching session vars in one particular app and had to add a cfheader tag to reload the page when they hit it. I don’t know if this will help you or not.

Please let me know if you find a solution to your problem. I would be very interested to find out how you solved it.

I’m thinking that this has more to do with the browser than anything else. I’ve added a check to the onRequest funtion in application.cfc… it will update a table and email me a dump of the cgi every time a session variable is unexpectedly missing. I’m hoping I’ll see a pattern.

Another weird thing is that I have another application running on the same server (different domain) and there are never any of these errors. I’m wondering if the number of sessions has something to do with it as well… the app which is dropping the variables averages about 1000 per day, while the app which is behaving is only around 250.

I’ll keep you posted

@Shawn

Egils mentioned in the comments above that there may be a cookie limit. If you google “browser cookie limit per domain” you will get some information on that.
Good Luck.

Good thinking, I’ll check that as well…Thanks!

Well, so far I’ve discovered that it’s happening with all type of browsers. I’m well under the limit on cookies, but even if I wasn’t, according to Microsoft, exceeding the limit only causes “older” cookies to be dropped, not the entire session, which is what’s happening. cgi.HTTP_COOKIE, which normally would show the CFID, etc is blank in all cases.

I have a couple of other things to try, like enabling the ratings for the domain.. I think that requires a restart of IIS, so it’ll have to wait for the weekend.

I’ll let you know what I find out …thanks!

@Shawn

Now you really have my curiosity up. Try starting at the beginning and make sure all the basics are covered like an App name in the Application.cfm (cfc), session management set, session timeout set, junk like that. Walk through from the very start.

Ok, here’s the application.cfc file (I’ve changed some values for copyright purposes):

I’m occasionally losing client variables in a CF7 cluster server environment, have only SetClientCookies=“yes”, SetDomainCookies is NOT specified. Could the above discussion be relevant? Thanks

@Shawn

The application.cfc didn’t come through in the comments section. You can email it to me: jen (at) jensbits (dot) com
Also, check the server. If the CF server is set to use J2EE variables (jsessionid), it will not use the CFID/CFTOKEN cookies to track the user’s session. It will use the jsessionid instead. So, if you are using J2EE session management on the server the CFID/CFTOKEN will not be set as session vars.
From http://bit.ly/T1HOs

If you use J2EE session management, the Session scope does not include the Session.CFID or Session.CFToken variables, but does include the Session.URLToken and Session.SessionID variables. In this case, the Session.SessionID is the J2EE session ID and Session.URLToken consists of the string jsessionid= followed by the J2EE session ID.

@Sycamore

You can try SetDomainCookies = “yes” but it didn’t work in my case because the browser was already doing that. Unfortunately, http://mysite.com and http://www.mysite.com were considered two different domains.

Sorry for the delay in replying…been a hectic day. Jen, I’ve emailed the application.cfc file to you.

Sycamore: I don’t think so…I’m using a single server with CF8..setClientCookies is true, setDomainCookies is false.

Jen: I’ve tried having J2EE session management both on and off, there doesn’t seem to be any difference with respect to this issue. I’ve also tried moving the entire app to a new domain… it was previously in a subdomain where the primary domain was hosting another app…after checking the logs though, no change. I’m going to try turning J2EE off again.

Thanks for the input!

No luck yet. Turning J2EE session management did’t change anything. I’m wondering if CF has issues supporting multiple domains?

Sorry it took so long to get back here. Since my last post I’ve done the folowing:
- merged the problem app into the same domain as a related app which has been behaving
- consolidated CFIDE folders…I’m using the tabs in CF 8 and had multiple versions of the CFIDE folder to generate different coloured tabs depending on clien preferences
- reduced the number of session vars being used to 20,
- made sure that all session var names were the same case (grasping a straws on that one)

While thre is definite improvement, there are still vars being dropped for no apparent reason. Sometimes the var will get dropped between the time the user fills out a form and the the update page is called via the submit button.

Can’t think of anything else to do at this point… other than a different profession

Hey guys,

I also just inherited an app at work and am also having this problem… but I think I may have narrowed it down to a very specific scenario because of the nature of the code I am looking at. I am not at my desk right now, but tomorrow I will post a little insight and maybe it will clear things up for all.

Hmmmmmm. I just started having this problem. Everything was working fine and then it all came crashing down because I’m using the J2EE with Session.sessionid to keep track of each user and now I get the error that session.sessionid does not exist. I dumped the session and sure enough all I have is the URL token. I tried killing the sessions and starting again but same thing. It won’t give me a sessionid. Weeeeeeerd. Unfortunately this is on a shared host so I can’t see what is going on in the backend. But it WAS working. [and the client just nods and says "uh huh. sure it was"]

I too am having this issue. So bizarre. I’m using an internal intranet behind my company firewall so its not a www issue.

It’s definintely related to upgrading to IE7 and not all users have the issue. I’m hoping though as more users update it doesn’t become one. I’ve sort of looked at it as a “black bug” either with IE or Coldfusion.

Any update on this? I’m pulling my hair out! You think it has anything to do with Windows registry? My client variables setting in CF8 Admin is set to Registry for a default storage mechanism for client machines. Not sure how that works though.

Basically what I think is happening is the session is timing out on the server before in the application. So what I do now is if I get this error, I capture it and then set the session timeout to 1 second. After 1 second I restart the session.

i dont think so (at least in my case). i’m seeing the cfid and cftoken sessions alive in my CF8 admin. its just that some users’ machines are not picking up the sessions based onthe cfids?

AHA. I finally figured it out after lots of google searching. In my application.cfc I needed to add the domain=”" to my cookie in the OnSessionStart function.

Not sure why this only affect SOME IE7 users and not others (it must be some sort of registry settings or something like that).

by adding the domain name in the following the issue was solved by all users!

………..rest of cffunction code here……

HOPE THIS HELPS ANY ONE ELSE!

Nice work, BosDog.

If you want to post your code give it another try. I just added a plugin to display code in comments. If you see code below this, it's working:

<a href="verybadlink.cfm">Link</a>

sure here was my code that got cut out in the last post:

<cffunction name="OnSessionStart">
<cfcookie name="CFID" value="#Session.CFID#" domain=".somedomain.com">
<cfcookie name="CFTOKEN" value="#Session.CFTOKEN#" domain=".somedomain.com">

………..rest of cffunction code here……

</cffunction>

Thank you for this post. I run into this issue every now and then, and I always have to work it out all over again, because of the time lapse between occurrences, coupled with my lousy memory. I knew it had something to do with the cfapplication tag, but couldn't remember what, and your blog and comments pointed me to the answer. Thanks again.

So maybe I am missing the answer here, but what you are saying is that we need to make sure that all of our links stay the same? Coldfusion will always give a new session for all subdomains, etc. It just doesn't make sense to me.

@Joe
Look at how the cookies are being set by the browser. I had cookies for both www and none-www prefixes domain names. Other people who commented had other fixes. Some worked, some did not. It seems to boil down to how the browser sets cookies. And, the only thing consistent there is inconsistency. Wow, browser inconsistency…where have I heard that before?

Joe, what it is saying is that you have to make sure you have consistancy as to how your links are set up. Among other things.
It is totally true that across the internet, http://www.mydomain.com is NOT the same as mydomain.com. A lot of people (most) don't realize that. This has even bitten the IRS in the butt. Somebody has taken http://irs.gov but this is NOT the same as http://www.irs.gov (the one you probably really wanted).