This is for the person who asked the question about client and session variables (and of course all you others who want to know...). And before you ask, "yes", it's in the ColdFusion FAQ I'm building. Before we talk about client and session variables, we need to briefly discuss the HTTP protocol and cookies. That will help clarify how ColdFusion tracks users. The HTTP protocol consists of a request-response pair. When a browser requests a webpage from a server, the server's response is to find the webpage on its hard drive and then send the file back to the browser. When the browser parses (reads) the webpage and finds there are references to 5 images, it then makes 5 subsequent requests to the server, one for each image. Those 5 requests are then fulfilled by the server finding the images on its hard drive and sending them back to the browser. The browser then uses the 6 files to display the webpage on the monitor. All of this happens very quickly and helps to hide the fact that displaying one webpage can be the result of a large number of HTTP request-response pairs. Each request that a browser makes to a server is said to be "stateless". That is to say, the server doesn't track a series of requests from a particular browser. Each request is independent of every other request. As long as the server has the IP address of the computer making each individual request, it has sufficient information to send the necessary file (resource) on its way. Certain websites, however, have a requirement to track users - sites with shopping baskets, for example. If the information about the products in a user's basket is stored on the server, that server needs to somehow track users to ensure that baskets don't get lost or mixed up. How, then, do we address the fundamental statelessness of the HTTP protocol? The answer is with cookies and a pair of values called CFID and CFTOKEN. A cookie is the name given to a simple string of text. Firstly, let's clear up how cookies work. Setting a cookie in a browser works as follows. The browser requests a file from a server. The server's response is to send back the file, along with a command to "set" a cookie in the browser. If the browser is configured to accept cookies, the cookie is said to be "set". Every time the browser makes a subsequent request from the same server, the cookie is returned to the server along with each request. For example, if we set a cookie in a browser that had a value NAME equal to FRED, every time the browser asked for another file from the same server, along with the request would come the information that NAME=FRED. If there were several browsers all making requests from one server, so long as they are all returning different NAMEs, we could use the cookie's NAME value to identify which browser each request had come from. ColdFusion utilises this behaviour to first differentiate and then track users. However, instead of using a cookie with a value called NAME, it uses two values called CFID and CFTOKEN. The first time a browser makes a request for a page from a ColdFusion server, ColdFusion creates a new CFID-CFTOKEN pair. CFID is an incremental number and CFTOKEN is a random 8 digit number. If the last CFID-CFTOKEN pair created was 100-12345678, the next pair might be 101-87654321. Taken together, each CFID-CFTOKEN pair is unique. When ColdFusion sends the first page back to the browser, it also attempts to set a cookie that contains our newly created CFID-CFTOKEN values. If the cookie is successfully set, every subsequent request from that browser will be accompanied by the cookie containing CFID=101*CFTOKEN=87654321. As long as ColdFusion then receives the CFID and CFTOKEN values along with every request (which is how cookies are designed to operate), it can differentiate requests from different browsers. Client variables are values stored on the server and associated with a particular browser. They are typically stored in the server's registry (a part of Windows where values are stored). Client variables are designed to track users over a long period of time. If a user visited a site and was asked to enter their name in an online form, and this code was on the following page <CFSET client.Name = form.Name> whatever they typed in the Name form field would then be stored in the registry as a client variable called "Name". Along with Name would be the CFID-CFTOKEN pair of the browser with which they are associated. The user then left our site and didn't return for several weeks. When they did return, the first time they request a page from the server, the CFID-CFTOKEN pair were also sent. ColdFusion sees that along with the request for a page is a value for CFID and CFTOKEN. If then looks to see if the CFID-CFTOKEN pair it has been sent with the request match any of the pairs stored in the registry. It does! And along with the CFID-CFTOKEN value in the registry is another value called Name which was set during the last visit. So, if ColdFusion is asked to display client.Name on the page , it can retrieve the Name value for that client from the registry and output it. When a visitor has left our site, we have no way of knowing if they will ever return. As our site receives more visitors over time, the number of client variables stored on the server will increase. To prevent the registry from overflowing, we need to have some mechanism for deleting unused variables. In ColdFusion, we determine a length of time after which we consider it safe to delete a user's variables. ColdFusion keeps a record of the last time a user visited a site and client variables are typically kept for 90 days. ColdFusion regularly goes through the registry and looks for client variables that belong to a user that hasn't visited in the last 90 days and deletes them. In this way, we don't tell ColdFusion when to delete a user's client variables. We determine a length of inactivity after which it can be considered safe to delete their client variables. If Fred visited our site and his name was set as a client variable, he may return to our site several times over the following month. On each subsequent visit, his client variable Name would still exist in the registry, tied to his CFID-CFTOKEN pair. Our ColdFusion server is told to delete client variables for users that haven't accessed the site in the last 3 months (90 days). If Fred visited our site 91 days after his last visit, his client variables would have been deleted and for Fred, client.Name would no long exist on that server. Session variables work in much the same way. However, instead of being stored in the server's registry, they are held in the server's memory. They are designed for holding transient values, only lasting for the length of one visit (one session) to our site. As they are intended to be used for holding values that are impermanent and that can be safely discarded after a visit, they are ideally suited to storing the contents of a shopping basket, for example. As memory is precious on our server, session variables are typically deleted after only 20 minutes of inactivity. Knowing what fickle things customers are, we are going to ask them to enter their current favourite colour using another online form. On the subsequent page, we have this code <CFSET session.Colour = form.Colour> Whatever they typed in to the form field named Colour will now be held in the server's memory as a variable called Colour, together with that user's CFID-CFTOKEN pair. On another page on the site, we display their favourite colour using the code <CFOUTPUT> <P>Today, your favourite colour is #session.Colour#</P> </CFOUTPUT> When the browser requests this page, it also sends the CFID-CFTOKEN pair previously set as a cookie. ColdFusion looks to see if there is a match in memory for the CFID-CFTOKEN value is has been sent. Again, there is, and along with those values is a variable called Colour, set to Red for this particular user. The page will then tell the customer that their favourite colour is Red. Our user's phone then rings and whilst they are distracted for a while, their browser doesn't request any pages from our site. After 20 minutes of inactivity, the server then deletes any session variables tied to that user. If they put the phone down after 21 minutes and refresh the page, session.Colour wouldn't exist on the server. We would have to code the page so that they didn't see an error message telling them that session.Colour was not defined. Session and client variables help the developer by removing the burden of having to track users. ColdFusion has a mechanism that does this automatically. There are, as you might expect, a few caveats. To use client and session variables, you must have an Application.cfm file, usually placed in the root folder of your website. In it, typically on one of the first few lines, you must give your application a name, using the CFAPPLICATION tag. You must then enable client and session variables, optionally telling ColdFusion their life-span. It is also possible to store client variables in locations other than the registry. You can alternatively set them as cookies in the user's browser or store them in a database on the server. <CFAPPLICATION NAME="EasyStore" CLIENTMANAGEMENT="yes" SETCLIENTCOOKIES="yes" CLIENTSTORAGE="registry" SESSIONMANAGEMENT="yes" SESSIONTIMEOUT="#CreateTimeSpan(0,1,0,0)#"> We've specified an application name. We've also explicitly told it to enable client management (ie to store client variables on the server), to try and set the CFID-CFTOKEN values as a cookie in the browser and that client variables should be stored in the registry. We also explicitly enabled session management (ie to store session variables in memory on the server) and that we want ColdFusion to delete session variables tied to clients after they haven't requested a page from our site for 1 hour. If our site is visited by a browser that has been configured to not accept cookies, when ColdFusion tries to set a cookie when returning the first page, it will fail. If we were to rely solely on the browser sending its CFID-CFTOKEN pair with every subsequent page request, we wouldn't be able to maintain state for that user. Translated into the real world, if this user added an item to their basket, on the next page their basket would be empty. ColdFusion, though, doesn't mind how it gets to see a browser's CFID and CFTOKEN values. Normally, it would receive them in a cookie. To cater for browsers that have cookies disabled we have to ensure that that CFID-CFTOKEN pair is sent along with each request by another means. We can append CFID and CFTOKEN values to URLs as a query string or embed them in forms as hidden fields. If the URL for the second page is coded on the first page like this <A HREF="page2.cfm?CFID=#session.CFID#&CFTOKEN=#session.CFTOKEN#">Page 2</A> when the request is sent by the browser for page2.cfm, it will also send with it's CFID-CFTOKEN pair. ColdFusion can then marry up requests for pages with client and session variables tied to that user. Alternatively, if the user submits a form to view page2.cfm, we could pass back the CFID and CFTOKEN values like this: <FORM ACTION="page2.cfm" METHOD="post"> <INPUT TYPE="hidden" NAME="CFID" VALUE="#session.CFID#"> <INPUT TYPE="hidden" NAME="CFTOKEN" VALUE="#session.CFTOKEN#"> <INPUT TYPE="text" NAME="Colour"> <INPUT TYPE="submit"> </FORM> When the form is submitted, the browser's CFID and CFTOKEN values would be visible to ColdFusion as form variables. Using client and session variables is made very simple by ColdFusion. However, if you wish to take advantage of them and still enable users with cookie-disabled browsers to visit your site, you must recode your site to provide an alternative means of passing pack the CFID and CFTOKEN values to the server. -- Aidan Whitehall <[EMAIL PROTECTED]> Netshopper UK Ltd Advanced Web Solutions & Services http://www.netshopperuk.com/ Telephone +44 (01744) 648650 Fax +44 (01744) 648651 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
