Kaz, is this in regards to the conversation we had yesterday about company
x choosing to use cookies over session vars because they think that
session vars use too much memory?
Let me start this conversation off with a quick question What If I
disable cookies :-)
Tell those networking guys
Subject: RE: Cookies vs Session Variables
Kaz, is this in regards to the conversation we had yesterday about
company
x choosing to use cookies over session vars because they think that
session vars use too much memory?
Let me start this conversation off with a quick question What If I
The fact is, if you have the hardware to support your needs (needs being
something you figure out) then you are fine.
What kind of proof do you need?
In the case of this argument, let's assume that cookies are
enabled for everyone.So we can eliminate those statements.
This is purely an issue
those statements.This is purely an
issue of how much does it hurt performance.
Kevin
_
From: Tangorre, Michael [mailto:[EMAIL PROTECTED]
Sent: Monday, April 05, 2004 1:48 PM
To: CF-Talk
Subject: RE: Cookies vs Session Variables
Kaz, is this in regards to the conversation we had yesterday
:[EMAIL PROTECTED]
Sent: Monday, April 05, 2004 2:49 PM
To: CF-Talk
Subject: Re: Cookies vs Session Variables
Kevin,
If your application requires a login and a password I'd strongly
recomend going the session rather than the cookie route for the
following reasons.
1) You can destroy sessions
Jeremy Brodie wrote:
[...]
For a sturcture containing user information a persistant cookie requires
a connection with local file system and then CF needs to parse out the
information contained in the structure. Every time you call the cookie,
you need to run through the same series of
Is there any performance gain to only using cookie variables
instead of using session variables?
No, I've never seen any performance issues with using session variables,
generally. In fact, I would expect that they'd perform better than cookies,
since those cookies would then have to be part
Nathan-- I agree here.
When browsing a web site, I'm sure modern browsers cache cookies for
whatever site you're viewing so the hard drive is accessed as few times
as possible.
variables, that information is in server RAM or in a nearby database
--much closer to the center of action.
switch to session vars, and pass the urltoken on every request and set the
setclientcookies attributes to no in the cfapplication tag. this last
bit is to prevent cf from correlating requests into a session via a cookie
on the user's machine.
cflocation will pass the urltoken automatically if
Nope. As a matter of fact, the way CF recognizes the session is through
cookies.
Run this code to confirm:
cfloop collection=#cookie# item=myVar
cfoutputCOOKIE.#myVar#/tdtd style=font: 12pt Courier
New#evaluate(COOKIE. #myvar#)#/cfoutput
/cfloop
You'll notice a CFID and a
Switching to session vars would eliminate the problem.
Shawn Regan
Applications Developer
Pacific Technology Solutions
-Original Message-
From: Pete Miller [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 02, 2001 12:55 PM
To: CF-Talk
Subject: Cookies vs. Session Variables
We have an
Cookies can be set to expire when the browser is closed. AFAIK, you can't
overcome this with browser configuration. Sounds like a change in a few
lines of your code will fix your problem. Using CFCOOKIE without
specifying a timeout will cause the cookie to vanish when the browser is
closed and
I have never seen this before. You must remember, session vars are still
based on cookies. So If you did move to session vars you would still have
the same problem.
At 12:54 PM 7/2/2001 -0700, you wrote:
We have an application that uses cookies to track the identity of a user
after logging in.
I've never heard of a lab setup like this, but certainly
don't doubt it. Is there some reasoning behind the
configuration?
Session variables, by default, use cookies to maintain
identity. You can disable this by using the
SetClientCookies=No in the CFAPPLICATION tag. If you do
this, you'll
You are correct, cookies should not be used to identify users at public
terminals. Most public terminals either disallow persistent cookies,
disallow all cookies or reset cookies after use (more common in
labs). Sharing cookies is a new one for me, but the problem is the same.
The answer
15 matches
Mail list logo