Skip navigation
Kevin Hausman
Currently Being Moderated

CFID and CFTOKEN changes from page to page

Sep 21, 2010 10:35 AM

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.

 
Replies
  • Currently Being Moderated
    Sep 21, 2010 10:51 AM   in reply to Kevin Hausman

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 21, 2010 10:54 AM   in reply to Kevin Hausman

    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!

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 22, 2010 6:21 AM   in reply to Kevin Hausman

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 22, 2010 11:01 AM   in reply to Kevin Hausman

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 12, 2010 9:25 AM   in reply to Kevin Hausman

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 12, 2010 9:31 AM   in reply to Kevin Hausman

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

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 12, 2010 9:40 AM   in reply to FSUKXAZ

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 12, 2010 9:40 AM   in reply to Eric Cobb

    Yeah, according to the CF 9 LiveDocs (http://bit.ly/cKprqn):

     

    "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.URLTokenjsessionid= followed by the J2EE session ID."

     

    It also states that CFIDE and CFTOKEN are use in "ColdFusion session management only" (and not J2EE session management)

     

    This may not be your problem, but I thought I'd throw it out there to help troubleshoot.

     
    |
    Mark as:
  • Dave Watts
    747 posts
    Mar 11, 2003
    Currently Being Moderated
    Oct 12, 2010 9:41 AM   in reply to FSUKXAZ

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 12, 2010 9:55 AM   in reply to Dave Watts

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 12, 2010 12:27 PM   in reply to Dave Watts

    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?

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 12, 2010 12:45 PM   in reply to FSUKXAZ

    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.

     
    |
    Mark as:
  • Dave Watts
    747 posts
    Mar 11, 2003
    Currently Being Moderated
    Oct 12, 2010 1:30 PM   in reply to FSUKXAZ

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 12, 2010 1:38 PM   in reply to Dave Watts

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 13, 2010 8:45 AM   in reply to Dave Watts

    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.

     
    |
    Mark as:
  • Dave Watts
    747 posts
    Mar 11, 2003
    Currently Being Moderated
    Oct 13, 2010 9:02 AM   in reply to FSUKXAZ

    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.

     
    |
    Mark as:
  • Dave Watts
    747 posts
    Mar 11, 2003
    Currently Being Moderated
    Oct 13, 2010 9:04 AM   in reply to 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.

     

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 13, 2010 10:28 AM   in reply to Dave Watts

     

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 13, 2010 10:32 AM   in reply to 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.

     

     

     

    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!

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 14, 2010 12:38 PM   in reply to Kevin Hausman

    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.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points