cfid AND cftoken appearing in URL

Report · Nov 12, 2008

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-C8855374E...

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,

Report · Nov 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.

Report · Nov 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.

Report · Nov 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 😉

Report · Nov 13, 2008

I think you got it, but I had to read the last post several times so I
may be misinterpreting it.

The main points are that the cfid and cftoken OR jsessionid (if J2EE
sessions is enabled within the administrator) is the key to connecting a
client request to existing session and|or client state data.

If the client does not provide a valid key to an existing session state,
either no key provided or the key is to an expired session|client data
instance, then a new session|client state is generated and new keys are
returned to the client to be used in future requests. These keys can be
passed either in cookies, the first choice, or get and|or post variables
(AKA url and form scopes).

I guess that you could monkey with this and provide the key to an
existing session to a new client request. This would be tricky as there
is no external, accessible list of current session keys of which I know.
You would have to either build such a store and the logic to maintain
it during the creations and expiration of session data collections. OR
uses some of the undocumented, but blogged about, access to the
ColdFusion java administration object(s) to inspect all current sessions
and retrieve the key data from within them. You would then have to over
ride the cookies and|or get or post variables the client is using to use
these values rather then the ones automatically generated by ColdFusion.

Report · Nov 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). . .

Report · Nov 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).

Report · Nov 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.