Client Variables

[CFRAM]

Help Needed,

Can any one please explain why do we loose client variables when we delete cookie variables from the browser ?

[CFRAM]

Apprently I saw a file in the Temporary Internet Files :

Cookie:admin@localhost/

Which has entries of CFID and CFTOKEN. When I delete this file my appliction looses all the access. Why ?

[Rupesh Kumar]

If you are using a variable with client scope, it is accessible to you
across browser session. How else can the server do it except using cookies.
Cookies send the identification of the client to the server and then based
on that id, server loads those variables and makes it available for you.
When you delete the cookies and the browser send a request, browser will not
be able to send your identification to the server and server will assume
that it is a new request from a new client. Hence a fresh application data
will be created for you.

Hope this answers your question. Please get back if you need any further
clarification.

Regards,
Rupesh.

"CFRAM" <webforumsuser@macromedia.com> wrote in message
news:d1o6rc$krt$1@forums.macromedia.com...

> Apprently I saw a file in the Temporary Internet Files :
>
> Cookie:admin@localhost/
>
> Which has entries of CFID and CFTOKEN. When I delete this file my
> appliction looses all the access. Why ?

[CFRAM]

Thanks for the information . Another quick question. If I delete the cookies
loosing CFID and CFTOKEN can I prevent from deleteing it ? If so how? Or if the
Cookies are disabled can the application pick CFID and CFTOKEN from CDATA and
CGLOBAL tables from the DB since my Client variable storeage is DB.

[Rupesh Kumar]

There is no way that the server can prevent the user from deleting cookies
because server can not have any control of user machine.

The purpose of client scope variable is to keep some user preferences with
the server so that they are available across the browser sessions. Client
variables are stored against the CFID+CFTOKEN in CDATA table. Now, if the
cookies are disabled, server does not have any way to locate his old data
(as there wouldnt be any CFID and CFTOKEN in the request) and hence the
variables for the client would not be loaded.

Only possible way to do it is that you always have registered users and you
store his data in DB against his userId.
You will have to manage this data yourself i.e load this data at the start
of the page using his user id and persist it when required.

rupesh

"CFRAM" <webforumsuser@macromedia.com> wrote in message
news:d1omo3$b6i$1@forums.macromedia.com...

> Thanks for the information . Another quick question. If I delete the
> cookies
> loosing CFID and CFTOKEN can I prevent from deleteing it ? If so how? Or
> if the
> Cookies are disabled can the application pick CFID and CFTOKEN from CDATA
> and
> CGLOBAL tables from the DB since my Client variable storeage is DB.
>

[sdwebguy99]

Perhaps a refresher as to how Client variables work would help you as well. To
clarify, client variables can be stored as a COOKIE or in a central database
repository. That is a separate issue from how the client variables are sent
back to the server after every request. You have two options: passing CFID and
CFTOKEN in the URL (or FORM) from one page to the next, or saving them as
cookies and having the browser send them automatically. Which way you choose
is determined by the CFAPPLICATION tag used in your application
('setclientcookies'). Hope this helps.

[tmagee]

We have a new guy here who setup CF to put this in the registry, the problem
of course is that the registry has grown. I put some patches in to have it
purge all data after one day and my question is will that also shrink the
registry back down?

[nedflanders]

What are they for and how long should you keep them?

Our CF server was keeping them in the registry for 90 days by default and it
brought our server to its knees every hour when jrun tried to clean up. We will
be moving them to a SQL server in the next few weeks. But what does CF use them
for and how long should you keep the data?

Thanks
NF

[MattRobertson]

Client variables are one of CF's persistent variable scopes. They are only for
storing simple data (structs are possible with cfwddx but this is a performance
hit).

The idea behind client variables -- originally -- was they could be used for
persistent values that span sessions. So if a visitor named 'Ned Flanders"
visits the site today, a week from now the site could say "Welcome back Ned
Flanders". CF updates two (I think) cvars automatically on every page visit:
client.hitcount and client.lastvisit. These are for the number of page visits
total the user has effected, and the last date/time of the last page visit,
respectively. Also stored is client.cfid and client.cftoken. These are the
minimum stored per site visitor (you can shut off page-by-page updates but
you'd better understand the implications to your app before trying that)..

Over the years client variables have been shoehorned into other uses. In
versions of CF prior to CFMX client variables stored in a common database were
the only way to maintain session data across a cluster. You used cvars in
stead of session variables since you could hit any one of the servers in a
cluster, and each stored its own svars, which was no use at all. Nowadays this
is no longer true.

You can also use cvars as persistent in-session storage without the need to
worry about locking (with the concurrent need to write up something that
expires them within minutes instead of weeks). However again, with the advent
of CFMX (i.e. CF6) the need for locking is reduced to protection against race
conditions and no longer necessary to maintain server stability.

So I think today we can say that the uses cvars were intended for are really
what the manual says, finally.

It is best practice to put cvars into a database. You've found one reason why
the hard way. It sort of goes without saying that the less you write to the
Windows registry, the better.

Bear in mind also that if you aren't using cvars there's not much point in
storing the records for 90 days and ballooning the cvar repository. Even if
you use them you'd have to look at and decide whether 90 days was too much (it
is for me and most of my clients). I use cvars but not for the long-term
persistence stuff. For me 10 days or less is fine. For you, I bet if you
don't even kjnow what cvars are that you could expire after one day. At least
for now.

Hope this helps,

--Matt--
MSB Designs, Inc. [url]http://mysecretbase.com[/url]
"As far as the laws of mathematics refer to reality, they are not certain;
and as far as they are certain, they do not refer to reality."
- Albert Einstein

[nedflanders]

Thanks for that overview! it answred a lot of questions.

NF