ClientManagement Required for Use of AddToken Param in Cflocation?

[Dordrecht]

Our CF2018 application handles sessions manually using cookies, but we found that cfid and cftoken params are appearing on the URL in some cases. I expected that these URL params might just be an unwanted side effect of coders forgetting to put addtoken="no" on their cflocation tags, so I coded addtoken="no" on all cflocation tags and that seems to have fixed that issue.

My concern is that during my analyis, I found that the Adobe docs say that ClientManagement must be set to true for the addToken param to work (From https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-tags/tags-j-l/cflocation.html😞

Our application has ClientManagement set to false, and yet the addToken param successfully passes or suppresses the URL params depending on the param value just fine. Why? Is this an error in the docs? I want to avoid any special case gotchas.

[Charlie Arehart · Accepted solution]

That is indeed just poor wording on their part. The point being made was rather that there'd be no reason to use the addtoken UNLESS you had enabled a feature that would leverage the tokens. 

And it's not only clientmanagement that would but also sessionmanagement (assuming you're not using j2ee sessions).

Bottom line, if you use neither then there's no use of tokens, and the addtoken would seem moot, but there's no reason to expect it to fail.

In any case, it would be trivial to test, in a new folder with its own application.cfc/cfm. (I'm writing on a phone, so not something I can do now. Let us know if you may try.)

Finally, note also that since cf11, if you enable the secure profile feature in cf, then you don't NEED to use addtoken to disable their use. It becomes a default of no, if none is used in a cflocation.

Oh, and you can file a bug report to point out the doc issue, at tracker.adobe.com. There's a category for doc bugs, and they do attend to them. 

[Dordrecht]

Thank you, Charlie Arehart. As mentioned, the addtoken param was doing what I wanted it to in my application, but that was on a Wednesday with the windows closed. I wanted to make sure there were no contingencies or dependencies that affect addToken's usability. More importantly, we all know it isn't safe to use elements of a language in ways contrary to the docs, even if they happen to work, because we can't rely on them to act the same way in future updates.

Thank you for the comment. I believe I can use cflocation with addtoken comfortably now despite clientmanagement being false.

There was a concerning detail I found in relation to Secure Profile being turned on. I found a work ticket in our system from 2014 (before my time with the organization) through which hundreds (all) of addtoken params having a value of "no" were removed from our application "in preparation for CF11", despite the fact that Secure Profile was apparently never turned on. That makes no sense to me, neither in relation to why that was done nor why addToken="no" wasn't put back into the code when it was realized that cfid and cftoken were appearing on the URL after CF11 was installed. For now, I'm just chalking it up to misreading the CF docs and a busy department for the last 7 years. It's just concerning to me.

As I am tasked with removing cfid and cftoken from the site's urls, I'm considering a safe course of action to be putting the addtoken params back into the code with an application variable set to "no" as the value. Then, if things go South when deployed, we can quickly change the application variable to "yes" until we evauate further.

Thanks again.