I recently found the reason we were seeing two sets of cfid and cftoken
cookies. We had code similar to this running:
cfif myvars.KillSessionOnClose and IsDefined(cookie.CFID)
cfset variables.LocalCFID=cookie.CFID
cfset variables.LocalCFToken=cookie.CFToken
cfcookie name=CFID
We finally resolved this issue.
First, a big thanks as always to everyone who commented and helped us along
on this thread.
Second, here is the resolution. In our case, the problem was some enhanced
security filters that we put place recently. One of the scopes being
scanned was the cookie
On Tue, Mar 11, 2014 at 11:52 AM, Dave Watts wrote:
No, I think you should only have the one cookie for jsessionid. I'm
not sure why you have the other two.
As you can imagine I did some reading on jsession vars after I opened up
this thread. Look at the comparison table here:
Hi there,
Thanks for your follow up post. It definitely seems that we have something
similar going on. We have switched some features to be less dependent on
sessions and more on other scopes. That has worked ok but longer term we
want sessions to work consistently.
It's been very difficult
Hi All,
I was just about to post on a very similar problem when I saw this thread.
We've just had this come up in the last couple of weeks and it happens
sporadically. A few quick points:- the problem is that sessions restart
with each request- the problem happens sporadically- the problem
I was just about to post on a very similar problem when I saw this thread.
We've just had this come up in the last couple of weeks and it happens
sporadically. A few quick points:- the problem is that sessions restart
with each request- the problem happens sporadically- the problem is solved
Hi Dave,
I may be getting a bit over my head here, but here is an example of what
our session dump looks like:sessionid: 84303380daf164aedda3456e2d1856513d2e
urltoken:
CFID=83197727CFTOKEN=9af68af80f73df3-F872B04C-CA42-C7AB-D8FB410E558AEEE5js
I may be getting a bit over my head here, but here is an example of what
our session dump looks like:sessionid: 84303380daf164aedda3456e2d1856513d2e
urltoken:
CFID=83197727CFTOKEN=9af68af80f73df3-F872B04C-CA42-C7AB-D8FB410E558AEEE5js
I recently tried switching to j2ee sessions and noticed the same thing,
that cfid and cftoken were still being created as well. So it isn't a
unique case.
On Tue, Mar 11, 2014 at 6:52 PM, Dave Watts dwa...@figleaf.com wrote:
I may be getting a bit over my head here, but here is an example
Thanks Dave,
I'm not really the developer here but I think that we may have client
variables enabled and my recollection was that client variables may require
cfid and cftoken.
It's been running pretty smoothly for a while until this very recent
issue.
Nick
I'm not really the developer here but I think that we may have client
variables enabled and my recollection was that client variables may require
cfid and cftoken.
It's been running pretty smoothly for a while until this very recent
issue.
Yes, client variables do require CFID and CFTOKEN.
Thanks Russ,
With client variables (we're phasing them out) in place as well as the more
secure j2ee session variables, we seem to have all in use at the moment.
But, I think that has been a pretty stable configuration for us for some
time.
Nick
One really interesting behavior here, which may point us in the direction
of a better solution, is that when this problem with session.jsessionid
happens (it resets ever page request), cookie.jsessionid remains
persistent.
I don't know enough about the linkage there to know if that is expected
check that you do not have any cflocation tags which are using
addtoken=yes (the default), this seems to be a fairly common cause of
superfluous cfid and cftokens cookies being created
as as per other thread, try completely removing the cookies or use
incognito mode to see if it persists, and
I think it was pretty clear that code he listed was being used solely to
diagnose a problem he was experiencing **on a production server** and
from **multiple client computers**, and that wasn't necessarily
reproducible on a development server. And I don't think the code was
meant for
Opening a private browser window will always solve the problem. With that
in mind, whats the best way to reset cookies on session start? I am using
application.cfm. What could cause this? Underlying CF code from the
current site has barely changed.
The problem, I think, is related to
+1 for J2EE sessions.
-Carl V.
On 3/7/2014 9:20 AM, Dave Watts wrote:
The best solution, in my opinion, is to switch to J2EE sessions,
assuming you can invest the time and effort to do that.
~|
Order the Adobe Coldfusion
On Thu, Mar 6, 2014 at 5:22 PM, Russ Michaels r...@michaels.me.uk wrote:
see if there are multiple cfid/cftoken cookies set.
if so, that is likely the issues, and deleting all cookies should solve it.
in your cflocation tags you need to use addtoken=no otherwise this can
cause problems
The best solution, in my opinion, is to switch to J2EE sessions,
assuming you can invest the time and effort to do that.
I'm having almost the exact same problem. My login system, had been
working perfectly (CF8) until we moved everything to a new server with
CF10 on it.
Now, Chrome will
try this
http://www.petefreitag.com/item/815.cfm
On Fri, Mar 7, 2014 at 6:34 PM, Gerald Guido gerald.gu...@gmail.com wrote:
On Thu, Mar 6, 2014 at 5:22 PM, Russ Michaels r...@michaels.me.uk wrote:
see if there are multiple cfid/cftoken cookies set.
if so, that is likely the issues, and
To: cf-talk
Subject: Re: CF session management suddenly not sticking ...
The best solution, in my opinion, is to switch to J2EE sessions,
assuming you can invest the time and effort to do that.
I'm having almost the exact same problem. My login system, had been
working perfectly (CF8) until we
IIRC, unless you explicitly access CFID/CFTOKEN in your code, there
shouldn't be any issues.
-Carl V.
On 3/7/2014 10:45 AM, Les Mizzell wrote:
So considering the above - what, in theory, would be the exact
consequences in switching to J2EE sessions? I don't this there would be
that much code
So considering the above - what, in theory, would be the exact
consequences in switching to J2EE sessions? I don't this there would be
that much code that would need to be changed. I'm simply checking that
session.isADMIN is true in my application file. I admittedly don't have
a
I forgot about the persistence issue. Personally, I consider the lack
of session persistence to be a security benefit. But not everyone will
agree.
-Carl V.
On 3/7/2014 11:17 AM, Dave Watts wrote:
If you're not directly referencing CFID and CFTOKEN in your code, and
you're not relying on
I think it was pretty clear that code he listed was being used solely to
diagnose a problem
Precisely. Its the production environment but not the production site.
I'm testing with some old in-office desktops that mimic the problem
reported to us by users when this site was live for roughly 24
I think by add on he might have been referring to a browser add-on or
plugin that the users have installed into Internet Explorer.
-Carl V.
Or maybe you have an add on that is killing cookies.
That was my very first thought and I went straight to the design team who
swore that we weren't
I was thinking html code but yes thats a possibility as well. However a)
my test units are plain vanilla XP/IE8 wkstns and b) the CF code in
question has been running fine for years on these same desktops. We use
the web site in-house on a daily basis.
Worth noting: The demo code you were
Are you sure no cfpatches have been installed, specifically the one in the
link I sent earlier.
Often people are adamant when they say no only to find someone else did it.
Russ Michaels
www.michaels.me.uk
cfmldeveloper.com
cflive.net
cfsearch.com
On 7 Mar 2014 21:03, Money Pit
Are you sure no cfpatches have been installed, specifically the one in the
link I sent earlier.
Well earlier I said
...it is CF9 with all patches.
But I should have said it is *9.01* with all patches. So yes APSB11-04
was definitely one of them. I subscribe to Foundeo's monthly (?)
Speaking of that linked article, I disabled the session fixation patch via
Pete's instructions (-Dcoldfusion.session.protectfixation=false in the JVM)
and so far I've got proper functionality. I've had inconsistent results
before this so I'm not declaring temporary victory just yet but this is
check the cookies that have been set in the browser, there are addons that
will show you this.
see if there are multiple cfid/cftoken cookies set.
if so, that is likely the issues, and deleting all cookies should solve it.
On Thu, Mar 6, 2014 at 10:09 PM, Money Pit websitema...@gmail.com wrote:
Well you were right I had multiple values, but problem persists. Ran code
below in OnRequestEnd.cfm and verified it was doing its job as expected
(deleting existing cookies, page reloads with new cfid and cftoken, and the
cReset cookie keeps it from happening all over again). The code didn't
so if you check the cookies after running your code, is there only one cfid
and cftoken, or is there still 2
On Fri, Mar 7, 2014 at 12:17 AM, Money Pit websitema...@gmail.com wrote:
Well you were right I had multiple values, but problem persists. Ran code
below in OnRequestEnd.cfm and
Nope I was down to one pair, and it was the pair just generated via the
cflocation. The code was doing its job.
Another repeatable mystery: If I turn down IE8's security from the default
of Medium-High to Medium it will always fix the problem. Same as with
Private Browsing.
On Thu, Mar 6,
in your cflocation tags you need to use addtoken=no otherwise this can
cause problems
the IE security setting may be down to the cookie acceptance policy, I
don't know why that would make a difference, but worth comparing the 2
settings to see how it differs.
On Fri, Mar 7, 2014 at 12:50 AM,
Yup I'm doing that. Put together a test page so as to take all of my code
out of the picture... although that back end has been fine for years... The
redesign was just a re-skin. But to be thorough I made this:
cfapplication
name=test_0915
sessionmanagement=Yes
clientmanagement=Yes
If you are going to be dumping things out in production, for the world to
see, I would stop that habit. The last thing you want to do is annoy your
clients / visitors with this stuff. People are not forgiving when they see
these things on the screen, personally if you have to do this, for god
37 matches
Mail list logo
