Skip to main content
Inspiring
November 12, 2008
Question

cfid AND cftoken appearing in URL

  • November 12, 2008
  • 5 replies
  • 6763 views
My app uses SESSION.var for isSignedIn() among other things. I've noticed though that SOMETIMES the URL in the browser has CFID & CFTOKEN appended as in:

http://www.website.com/olo/index.cfm?CFID=2012&CFTOKEN=b1b6490b886ce47b-69F76C6B-9B58-BE30-C8855374E8763937

I assume this is due to the server needing to track the session but does this have to be appended to the URL (my understanding is that the same info is sent NOT in the URL on each roundtrip anyway though I may need to be corrected on that).

Or is this a consequence of my (I think) NOT enabling this info to be written as a cookie (which would go every roundtrip).

And regardless, am I right in assuming that if it is part of the url (that appears in the browser area) then it is sent every round trip as a factor of this (ie if I submit a form then the form.data plus the info appended to the URL are both submitted).

Thanks in advance,
This topic has been closed for replies.

5 replies

Inspiring
November 17, 2008
ProjectedSurplus wrote:
>
> If you don't mind could you briefly set out the case for using J2EE sessions?
> I've read up and assume they are accessible to say AJAX or Flex but don't see
> why cfid/cftoken couldn't be used for these (esp Flex).
>

Yes cfid/cftoken and jsessionID are the same for AJAX and Flex. Where
jsessionID J2EE sessions are usefully is with shared JSP code. A
jsessionID will be natively shared between JSP and CFML pages and can
maintain a single session between both.

Also jsessionID are automatically 'memory' cookies that expire with the
closing of a client browser. CFID/CFTOKEN cookies are 'persistent'
cookies by default and will live from one browser instance to another
unless manually configured to be 'memory' only with the <cfcookie...> tag.
Inspiring
November 14, 2008
Yes, thanks for the confirmation. I'm not so ambitious as to get into the java admin objects but its good to know where to start if the need ever arises so thanks again.

If you don't mind could you briefly set out the case for using J2EE sessions? I've read up and assume they are accessible to say AJAX or Flex but don't see why cfid/cftoken couldn't be used for these (esp Flex).

Inspiring
November 13, 2008
Prob more important is if you experienced guys might suggest how often NOT using cookies to write the CFID/CFToken is an issue (i.e. what rough percentage of visitors tend to have "Allow Cookies" turned OFF in their browsers)?

What about the % browsers with "Disable Scripts" ? (not sure if my terminology is right but). . .
Inspiring
November 13, 2008
ProjectedSurplus wrote:
> I assume this is due to the server needing to track the session but does this
> have to be appended to the URL (my understanding is that the same info is sent
> NOT in the URL on each roundtrip anyway though I may need to be corrected on
> that).
>
> Or is this a consequence of my (I think) NOT enabling this info to be written
> as a cookie (which would go every roundtrip).
>
> And regardless, am I right in assuming that if it is part of the url (that
> appears in the browser area) then it is sent every round trip as a factor of
> this (ie if I submit a form then the form.data plus the info appended to the
> URL are both submitted).

Yes, the CFID and CFTOKEN values must be sent by the client browser with
every request to the server for the server to know which session
instance to which the client belongs.

The normal, default behavior is for these values to be set and sent as
cookies. If cookies are not allowed then they must be sent as get (AKA
URL) or post (AKA FORM) variables with every request from the client
browser. There are mechanisms built into ColdFusion to aid in this such
as the addToken parameter of the <cflocation...> tag, the
urlSessionFormat() function and the client.urlToken or session.urlToken
variables.
Inspiring
November 13, 2008
quote:

Originally posted by: Newsgroup User

Yes, the CFID and CFTOKEN values must be sent by the client browser with
every request to the server for the server to know which session
instance to which the client belongs.




So this then is essentially a shortcut for the cf app server right?

Specifically, whenever a browser requests a page from the cfserver that cfserver checks the URL and then cookies to see if there is sent in one of those two locations a CFID/CFToken.

If info in URLorCookie then it checks (I presume CLIENT.vars and SESSION.vars) for associated data etc etc

If not info in URLorCookie then CFID/CFToken received then it creates a new one -- the upshot of which is the CFID/CFToken data is NOT derived (solely at least) from params inherent to the browser/PC/location etc.

Per another post I made, is there anyway to overwrite the (new) CFID/CFToken info if say through a login process I was able to determine for sure that visitor B is the same as visitor A for whom a CFID/CFToken were already assigned?

FWIW I'm not even sure it would be useful to do so thus dont spend much time on it . . . and as always thanks in advance for all the time spent helping us noobs ;)
November 12, 2008
If you are using a cflocation tag somewhere, you can add addtoken="no" to your cflocation tag and it will not send that CFID & CFTOKEN information in the URL. Depending on how your application is set up this may or may not cause things to stop working.