CFID and CFTOKEN changes from page to page

[Guest]

We have a closed network running CF 8.0.0.176276 version. My issue is with session variables cfid and cftoken. As I am navigating around the site the cfid and cftoken and always changing which sucks for tracking actually logged in website admins. We have the same exact code on another network but it is running CF 8.0.1.195765 and it works great. If I pass say cfid and cftoken in the url everything works.

I have opened server monitor and viewed the number of active session to IP addresses and we have only about 7 users but those 7 users together created close to 700 active sessions. Any help is great, I've Googled this issue and tried workarounds but if no one experienced this issue I guess I can patch it to match our other server.

I have made a simple version of this issue with a single cfapplication tag with all the required fields in a application.cfm and a single index.cfm file with one link to itself and a cfdump of session structure all in a new folder. When I click the link the cfdump of session shows a new cfid and cftoken value each and every single time... Thanks.

[Mike_Chabot]

It sounds like cookies are not being saved. It could be that a

firewall is stripping them out. The first thing to try would be a

different Web browser to see if the problem remains. If the problem

goes away then it is likely an issue with one of the browser settings.

Another easy thing to check would be the session settings in CFAdmin.

Maybe the timeout is too low.

For more complex troubleshooting, I would run a tool like Live HTTP

Headers or Fiddler to inspect the raw HTTP traffic and make sure the

cookie values are being sent back and forth.

-Mike Chabot

[Guest]

The cookies between the two servers are different. The one that works has more session information such as HasSessionScope true while the one that doesn't work has just cfid and cftoken defined. The CFAdmin session timeout is default to 20 mins and havn't touched it since installation. Thanks Mike!

[Owainnorth]

It's not entirely clear whether this is sorted or not, but in case it's not or for future reference, I had this issue the other week. Turned out that Client Management in CFAdmin was still set to Registry, and the user CF was running as did not have access to the Registry, hence every page hit got a new ID.

Changed it to use a database for Cfclientstore, job done.

[Guest]

I tried setting up storing the client vars in a database and no luck. Thanks for the idea though.

[Mike_Chabot]

Are you having issues with client variables or session variables? If

you are not using client variables in your site you should turn them

off to simplify the troubleshooting. I see many sites with client

variables turned on, but very few sites actually use them.

-Mike Chabot

[josh_adams1]

This is an interesting issue--has it afflicted you always or just recently? Given that this is ColdFusion 8.0 and the installer for ColdFusion 8.0.1 has been the only ColdFusion 8 installer available for about 2.5 years, I'm guessing this just cropped up.  So if that's true, what changed?

Regardless, though I don't know if it will help this issue, we do very much encourage all ColdFusion 8.0 users to...upgrade to ColdFusion 9.0.1! Well, okay, if you're not going to do that, we encourage you to update to ColdFusion 8.0.1 as you have on your other server.  And while you're at it, check out the ColdFusion 8 security bulletins at http://www.adobe.com/support/security/#coldfusion--these are critical!

[Guest]

We just copied over code from the other server since we are updating to a new design and this design has a admin area which admins log into. That is when we found out about this weird issue. We are getting CF9 but maybe in the meantime I will talk to our server admins to get it patched 8.0.1 and see what results I get. Thanks Josh!

[Guest]

Since this works on 8.0.1 version I am just going to patch the server. I want to believe this is a bug in the 8.0 version and was answered with the released patch. Thanks for all the inputs!

[FSUKXAZ]

Hi all, I work with Kevin.  I had the server guys update Coldfusion to the 8.0.1 and all the patches.  Still didn't work.  I put in a ticket to have the crappy IE8 browser rolled back to IE7.  Today they came and completed that IE8 is gone.  We're running IE7 now.  We're using same code as on other network.  All the settings in CFADMIN match perfectly.  So what gives?   Session variables still don't persist from page to page.  The thing Kevin and I see is the CFID and CFTOKEN changing.

Todd

[ilssac]

Also realize that the Browser and it's settings can affect the generation of CFID and CFTOKEN values.

These values are, usually, set as cookie values.  IF the browser, or anything between the browser and the server (virus|malware interceptors, proxy servers, etc) prevent these cookies from being saved and returned to the server with future requests, the server will generate a new set of values and return them to the client.

When diagnosing this type of difficulty one must follow the requests completely from one end of the conversation to the other... application server all the way to the client browser and back.

[Dave Watts]

Session variables are associated with the browser using cookies, by default. So, it sounds to me like either the cookies aren't being set by the server, or they're not being returned by the browser. You can use a tool like Fiddler2 or HTTPWatch with IE to view HTTP traffic.

If the cookies aren't being set by the server, you may have turned that functionality off in your CFAPPLICATION tag (Application.cfm) or application properties (Application.cfc). If the cookies aren't being returned by the browser, you may have some settings in IE preventing this.

If you're using J2EE sessions, as someone else mentioned, you should see a JSESSIONID token instead. However, I don't think you'd see CFID and CFTOKEN at all in that case.

Dave Watts, CTO, Fig Leaf Software

http://www.figleaf.com/

http://training.figleaf.com/

Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on

GSA Schedule, and provides the highest caliber vendor-authorized

instruction at our training centers, online, or onsite.

[ecobb]

When using J2EE session, the CFID and CFTOKEN will still show up in the

debugging output, CF just ignores them in favor of the JSESSIONID.

Thanks,

Eric Cobb

ECAR Technologies, LLC

http://www.ecartech.com

http://www.cfgears.com

[FSUKXAZ]

We're not using J2EE session variables. The CFAPPLICATION tag is set properly. The session variables are being set and the admin page is being shown with links to the admin pages.  However, as soon as you click one of the links the session variables are lost.  Even if you go up to a drop down menu and click on something totally unrelated the session variables are lost on the next page.  We have a security cfc returning the user/admin to the logon screen as soon as they're lost. Something in the browser, server, or firewall is messing this all up.  Ideas?

[ilssac]

FSUKXAZ wrote:

Something in the browser, server, or firewall is messing this all up.  Ideas?

Fairly likely, yup.  Only idea I can think of is to track down what is "messing this all up."  Since you earlier said that this only happend with a subset of all the users, I would start with what is unique about those users.  Most likely their browsers and then their client machine.  Confirm that they are getting and returning the cookies.  If that does not pan out, start working back towards the server until you find what is causing the problem.

[Dave Watts]

I suggest you use a tool like Fiddler2 or HTTPWatch to see if the server is sending the cookies, and if browser is returning them. Your browser may be ignoring the cookies altogether. Since you're using IE, you might also check your security settings in IE.

Dave Watts, CTO, Fig Leaf Software

http://www.figleaf.com/

http://training.figleaf.com/

Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on

GSA Schedule, and provides the highest caliber vendor-authorized

instruction at our training centers, online, or onsite.

[ecobb]

If it's IE only, you may also want to look at what else you have open in

the browser (if anything). We ran into a problem once where Outlook Web

Access kills all authenticated sessions in IE 8. http://bit.ly/LxQF1

Thanks,

Eric Cobb

ECAR Technologies, LLC

http://www.ecartech.com

http://www.cfgears.com

[FSUKXAZ]

Dave, we cannot use any tools like that.  We maintain these sites on classified networks and don't have permissions to download anything at all. Also, the servers are at remote locations. Lastly, we have no access and no control of security settings in IE. If that's an issue I can submit a ticket, but I would almost have to provide the solution to the people who do that work here on base. And again, everything works fine for us on another network running the same site and same code.

ilssac, you misunderstood. The admins are all users with vaying degree's of access.  Less than 20 people are in the total group. We all are the admins and this effects everyone in the group.  To be precise, that has nothing to do with the Session variables not persisting from page to page.

[Dave Watts]

Good luck, then!

But seriously, if you can't use tools to do your job, you're kind of screwed. But there's probably someone in that environment who can use those tools - maybe not installing downloads from the internet, but a network administrator who has a traffic monitor and can view the requests and responses.

As for looking at IE, are you saying you can't view security settings? They might be grayed out, but you should be able to look at them. Are requests passed through a proxy server? You might be able to get the manager of the proxy server to let you view request traffic.

Dave Watts, CTO, Fig Leaf Software

http://www.figleaf.com/

http://training.figleaf.com/

Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on

GSA Schedule, and provides the highest caliber vendor-authorized

instruction at our training centers, online, or onsite.

[FSUKXAZ]

But seriously, if you can't use tools to do your job, you're kind of screwed. But there's probably someone in that environment who can...

Ha ha!  Welcome to Kevin's and my world Dave!  Yeah, and the ones who can either don't care, or more importantly consider our group and our division a lower priority. We work in a constantly changing environment, and we're directly supporting the war fighter. Somehow we've been able to navigate through this sea of BS here for 4 years and actually get some quailty work done.  A good chunk of our time isn't coding, but is finding out ways around problems and coming up with solutions that aren't ideal but are fast, and in some crazy way, get the job done.

[Dave Watts]

Oh, and another thought. You could log requests to CF, and then you could see if the requests contain the session cookies. Use GetHttpRequestData to read the appropriate headers.

Dave Watts, CTO, Fig Leaf Software

http://www.figleaf.com/

http://training.figleaf.com/

Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on

GSA Schedule, and provides the highest caliber vendor-authorized

instruction at our training centers, online, or onsite.

[FSUKXAZ]

Oh, and another thought. You could log requests to CF, and then you could see if the requests contain the session cookies. Use GetHttpRequestData to read the appropriate headers.

This is a good idea.  We're going to try that.   I'll post the final solution when we get it. Thank you for your help!

[Guest]

Using that function I see no cookies under the header's structure which doesn't surprise me. IE issue?

[ilssac]

Kevin Hausman wrote:

IE issue?

IE or IE configuration are two real possibilities, and most definitly worth starting with.

But there are also other causes between the browser and the server that could be stripping the cookies.  So if the browser does not pan out, start looking at those.  I.E. Anit-spam|malwar tool, proxies, etc.

[ecobb]

If "Use J2EE session variables" is checked in the CF Admin, I believe you'll get a new CFIDE and CFTOKEN on every request.