Is there ever a reason to use the registry? Maybe if the OS
needs to access the vars?
No, there's never a reason to use the registry. That option is available
solely for backward compatibility. When Client variables were introduced in
CF 2, that was the only place they could be stored.
Dave
We've had a similar problem a few months ago... I'm not exactly sure what
caused it, but it seems that the CDATA table was owned by a different user,
and therefore coldfusion was not seeing it, because it was not owned by dbo.
Check your database, I bet that's what happening. As to the cause,
Hmm, nother long shot.Do you have the trusted cache set to yes?It migth
be remembering an old setting?
DRE
-Original Message-
From: Evan Lavidor [mailto:[EMAIL PROTECTED]
Sent: Friday, February 06, 2004 11:45 AM
To: CF-Talk
Subject: Re:Client vars won't go into the db?
Yep.I'm
Hi Evan,
Does your cfapplication tag for this app (probably in application.cfm)
specify something else? You can ovveride the default storage there.
Stefan
-Original Message-
From: Evan Lavidor [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 05, 2004 11:16
To: CF-Talk
Subject:
Are you absolutely sure you have only one application.cfm?
DRE
-Original Message-
From: Evan Lavidor [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 05, 2004 9:16 AM
To: CF-Talk
Subject: Re:Client vars won't go into the db?
...and a as followup, client variables on our MX servers
The DSN stuff will need to be already setup in the admin.
So you will need to create a DSN (Passing in the Username and password (im
pretty sure you cant have the password passed in later))
Then in client variables section of the Admin, you must register the DSN as
a ClientVariables DSN (but you
yup but I can't pass the username or password into the DSN as is on a shared
server and anyone could hijack the DSN then
-Original Message-
From: Mike Townend [mailto:[EMAIL PROTECTED]
Sent: 25 July 2003 13:46
To: CF-Talk
Subject: RE: Client Vars
The DSN stuff will need to be already
[mailto:[EMAIL PROTECTED]
Sent: Friday, July 25, 2003 13:53
To: CF-Talk
Subject: RE: Client Vars
yup but I can't pass the username or password into the DSN as is on a shared
server and anyone could hijack the DSN then
-Original Message-
From: Mike Townend [mailto:[EMAIL PROTECTED]
Sent
/isp.cfm?isp_id=772
==
If you are not satisfied with my service, my job isn't done!
- Original Message -
From: Andy Ewings [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Friday, July 25, 2003 7:53 AM
Subject: RE: Client Vars
| yup but I can't
when you say on a selective basis - what basis is that selection made?
-Original Message-
From: Doug White [mailto:[EMAIL PROTECTED]
Sent: 25 July 2003 14:18
To: CF-Talk
Subject: Re: Client Vars
There must be a security hole in the server configuration then, because it
is
relatively
Mike Townend wrote:
You could sandbox the DSN off... That way only your app could access it ?
Can you? The way I understand the Java security model is that in
the end it can only protect the file system and the network, i.e.
you can set permissions on files and directories and you can set
'...
- Thomas Paine, The American Crisis
-Original Message-
From: Chris Norloff [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 09, 2002 8:19 AM
To: CF-Talk
Subject: Re: Client Vars again
To ensure our logged-out (or timed-out) user is completely removed from our
application, we delete:
1
To ensure our logged-out (or timed-out) user is completely removed from our
application, we delete:
1. the entire session structure,
2. all the client vars (one at a time),
3. set the cookies to delete, and
4. use non-persistent cookies anyway.
I know that sounds redundant, but it's been
]
+---+
...'If there must be trouble, let it be in my day, that my child may have
peace'...
- Thomas Paine, The American Crisis
-Original Message-
From: Chris Norloff [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 09, 2002 8:19 AM
To: CF-Talk
Subject: Re: Client Vars again
To ensure our
On 9/8/02, Joe Bastian penned:
Susan,
Cflocation is a client side redirect .. in effect it changes the
header info
of the clients browser to the new url page.. so NO variables will be
set by the caller.
Any local/session/client/application variables, and queries, etc.,
will
Cflocation is a client side redirect .. in effect
it changes the header info of the clients browser to
the new url page.. so NO variables will be set by the
caller.
Any local/session/client/application variables, and
queries, etc., will work as normal on any code before
the
On 9/8/02, Joe Bastian penned:
Cflocation is a client side redirect .. in effect
it changes the header info of the clients browser to
the new url page.. so NO variables will be set by the
caller.
On 9/8/02, I penned:
Any local/session/client/application variables, and
meta tags or Javascript as i mentioned before..
you dont have to deal with changing any code...
Joe
- Original Message -
From: Bud [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Sunday, September 08, 2002 10:20 PM
Subject: RE: Client Vars again
On 9/8/02, Joe Bastian penned
PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Friday, September 06, 2002 3:50 PM
Subject: RE: Client Vars again
Hi Susan,
Can you give full details. Db, os, whats the applciation,
intranet/extranet/web,cfserver details,cluster/singleserver?
Have you tried session vars or homegrown client vars
Hey, looks like you posted this to cf-talk... again... !
On Fri, 6 Sep 2002, Adrian Lynch wrote:
I've posted this to CF-Talk, sorry for any who get both and don't like cross
posts...
Is there anyone out there that's built reliable login/logout functionality
into their site? Something that
Adrian:
I posted to CF-Talk several times yesterday (with no useful results) with a
similar problem regarding client vars. We are now re-engineering to write
cookies instead. I had posted a notice from MM about cflocation
addtoken=yes incrementing CFID. Look at your CFID table; we had new
-
From: Susan Hamilton-Allen [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 06, 2002 12:50 PM
To: CF-Talk
Subject: RE: Client Vars again
Adrian:
I posted to CF-Talk several times yesterday (with no useful results) with a
similar problem regarding client vars. We are now re-engineering
the variables in memory successfully.
Susan Hamilton Allen
Web Programmer
Pfingsten Publishing, L.L.C.
Seven Hills, OH 44131
-Original Message-
From: Andre Turrettini [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 06, 2002 3:51 PM
To: CF-Talk
Subject: RE: Client Vars again
Hi Susan
to
actually carry the variables in memory successfully.
Susan Hamilton Allen
Web Programmer
Pfingsten Publishing, L.L.C.
Seven Hills, OH 44131
-Original Message-
From: Andre Turrettini [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 06, 2002 3:51 PM
To: CF-Talk
Subject: RE: Client Vars
]]
Sent: Friday, September 06, 2002 4:18 PM
To: CF-Talk
Subject: RE: Client Vars again
how did you confirm that the client vars are not being recorded in DB?
+---+
Bryan Love
Macromedia Certified Professional
Internet Application Developer
Database
with that!
DRE
Ps. It's a stressfull thing so be thorough and clear minded!
-Original Message-
From: Susan Hamilton-Allen [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 06, 2002 2:13 PM
To: CF-Talk
Subject: RE: Client Vars again
DB: SQL Server 2000; Client OS: win2k; intranet app; single
: Friday, September 06, 2002 1:23 PM
To: CF-Talk
Subject: RE: Client Vars again
Well, I opened the CFID and CFGLOBAL tables and the rows corresponding to
the CFID/CFTOKEN in the dubugging results were not there.
Susan Hamilton Allen
Web Programmer
Pfingsten Publishing, L.L.C.
Seven Hills, OH 44131
Message-
From: Bryan Love [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 06, 2002 1:39 PM
To: CF-Talk
Subject: RE: Client Vars again
remember that the CFID can come from the following scopes:
- session
- cookie
- client
- url
I don't know the order these are searched in when no scope
.
Seven Hills, OH 44131
-Original Message-
From: Andre Turrettini [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 06, 2002 4:29 PM
To: CF-Talk
Subject: RE: Client Vars again
Hmm. I'm assuming that when you say we ran the app on another pc in the
office, you mean that you made requests
'...
- Thomas Paine, The American Crisis
-Original Message-
From: Susan Hamilton-Allen [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 06, 2002 2:02 PM
To: CF-Talk
Subject: RE: Client Vars again
We are not talking cookies here. We were using client variables written to
a database
: 216.328.8926
fax: 216.328.9452
-Original Message-
From: Bryan Love [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 06, 2002 4:55 PM
To: CF-Talk
Subject: RE: Client Vars again
let me expand on that a little
The ONLY way the server knows who you (the client) are is by you passing
:12 PM
To: CF-Talk
Subject: RE: Client Vars again
Thanks, but the problem was not with cookies. This is the MM posting I
posted yesterday. As I said, we also changed addtoken to no and
experienced other more puzzling problems. We are now using cookies, no
problems.
MM Forum posting:
July 16
VALUE=#session.cftoken#
/CFLOCK
This also has the benefit of closing a session when the browser closes.
-Original Message-
From: Bryan Love [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 06, 2002 2:19 PM
To: CF-Talk
Subject: RE: Client Vars again
keep in mind that you probably were
There is one other way of keeping the CFID and CFTOKEN
without cookies and not having to pass with every url
in you application.cfm file you can do:
CFLOCK TIMEOUT=30 THROWONTIMEOUT=No TYPE=EXCLUSIVE
SCOPE=SESSION
CFCOOKIE NAME=CFID value=#session.cfid#
CFCOOKIE
[mailto:[EMAIL PROTECTED]]
Sent: Friday, September 06, 2002 5:19 PM
To: CF-Talk
Subject: RE: Client Vars again
keep in mind that you probably were using cookies before, you just didn't
know it. Unless you specify cfapplication... setClientCookies=no then
cookies will be used. If you do specify
Hamilton-Allen [EMAIL PROTECTED]
Date: Friday, September 6, 2002 3:53 pm
Subject: RE: Client Vars again
Yes, that is true. However, I am aware of the SetClientCookies
option, and
did have it set as no. We really didn't want to write anything
to the
client at all.
Susan Hamilton Allen
Web
Yes, that is true. However, I am aware of the
SetClientCookies option, and did have it set as
no. We really didn't want to write anything to
the client at all.
If you want state management within your application, the browser has to
identify itself to the server on every subsequent page
:19 PM
To: CF-Talk
Subject: RE: Client Vars again
keep in mind that you probably were using cookies before, you just didn't
know it. Unless you specify cfapplication... setClientCookies=no then
cookies will be used. If you do specify ...cookies=no then you MUST pass
CFID and CFTOKEN in the url
I have client vars working fine on an ODBC connection
to the default tables CF set up for me in Master.
Then methinks, its a good idea to have client vars for
the app stored in the same db as the one for the app.
(WIN2K - CF5 - OLEDB - SQL Server 7)
In the first instance, when
Well this is what I have done, and it works just fine.
My server people won't like it though. They are firmly of the opinion
that OLEDB -- SQL Server is much more stable than ODBC -- SQL
Server. (and the reverse with connections to Access)
Strange that it says in CF_administrator To
#
/cfif
-Original Message-
From: Andrew Scott [mailto:[EMAIL PROTECTED]]
Sent: 11 February 2002 07:00
To: CF-Talk
Subject: RE: Client Vars expiring? When?
Mike,
Are you sure that you are expiring the CFID CFToken each and every
time in the application.cfm template. I posted code
Mike,
Are you sure that you are expiring the CFID CFToken each and every
time in the application.cfm template. I posted code in the CF Aussie
mailing list that will do what you want it to do.
-Original Message-
From: Mike Kear [mailto:[EMAIL PROTECTED]]
Sent: Monday, 11 February 2002
No, I'm using IE 5.5. I have tested the site with ie6, and it was working
fine.
-Original Message-
From: Mark Smyth [mailto:[EMAIL PROTECTED]]
Sent: 14 December 2001 10:54
To: '[EMAIL PROTECTED]'
Subject: client vars
are you using ie6?
Mark Smyth
Internet Systems Developer
SUeBS
00
You are correct in your understanding of client vars.
If you are using cookies to store client vars then keep in mind that cannot
use a CFLOCATION after a CFSET CLIENT statement. The following will
cause the client var not to be set:
cfset client.userID = 1
cflocation url=home.cfm
Also,
If you are using cookies to store client vars then keep in
mind that cannot use a CFLOCATION after a CFSET CLIENT
statement. The following will cause the client var not to be
set:
cfset client.userID = 1
cflocation url=home.cfm
This isn't necessarily true. You can't use CFCOOKIE
-
From: Adrian Cesana [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 01, 2000 5:53 PM
To: CF-Talk
Subject: RE: client vars
Thanks Cameron, I dont have the need currently to use the client vars so I
just want to clear em out of the registry.
I set the "Purge data for clients that r
na [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 01, 2000 8:53 PM
To: CF-Talk
Subject: RE: client vars
Thanks Cameron, I dont have the need currently to use the client vars so I
just want to clear em out of the registry.
I set the "Purge data for clients that remain unv
If you are still planning on using client vars in your app, I would change
to using a DB for client storage. Using the registry is bad (IE: refer to
original post).
You can make CF "expire" client info which is older than X days by changing
a setting in the cfadmin. I think the default for
Thanks Cameron, I dont have the need currently to use the client vars so I
just want to clear em out of the registry.
I set the "Purge data for clients that remain unvisted" to 1 day, then
stopped and restarted but nothing got purged.
In CFAdmin under "Variables" I have 2 options:
1) Enable
In the CF Administration there is a setting that will purge data from the
registry every nth day. I think it deafults to 9 months, all this means is
easier house cleaning. Best bet, use cookies rather than the registry as the
storage type!
regards
Andrew Scott
Senior Cold Fusion Application
50 matches
Mail list logo
