This is (not so) briefly how I understand the session & client scopes in CF:
Session variables: Session variables are stored in memory on the SERVER. Each session is referenced by a unique session identifier (JSESSIONID or CFID/CFTOKEN pair). HTTP is stateless, there is no inherent way to say "this request is part of that session". So in for the server to work this out some information has to be passed back & forth between the server & the client on each request/response. This information is the session identifier (JSESSIONID or CFID/CFTOKEN pair). The first time a browser hits a CF page the CF server makes a new session, creates the session identifier & gives this back to the client, this is kind of like the session PIN number. The client then uses from them on to access its session on the server. On each subsequent request the client sends this session identifier along with its request (POST or GET) and the server can then match the request up to the session. There are two ways that this session identifier can be sent back; either in the URL or in the HTTP headers as cookie data. This might look something like this when it goes over the wire: Cookie: JSESSIONID=96301828141074585835953; CFTOKEN=9c76f3e1c540c048-324E99B1-E168-32E6-4F58135858045667; CFID=211501 Regardless of which method is used the server looks at the PIN, works out if the session is valid and if it is it will use the relevant session variables. Ok so what is the difference between using cookies & or the URL. Well some fools don't allow cookies in their browsers and/or some developers can't work out how to support IE's privacy policies correctly (its not exactly easy but you can usually get around everything but the highest privacy setting if you implement P3P - www.w3.org/P3P/). When cookies fail you can revert to passing CFID/CFTOKEN through the URL. At the end of the day there are really no major differences in terms of security or anything else. Small side note - I've heard people say that CFID/CFTOKEN is insecure because people sitting in the middle (like at an ISP) can sniff the URL & hijack the session. Well cookies are no different, the information is still going across the wire in plain text & anyone who can look at the HTTP headers can hijack the session. The only way to secure sessions is the use HTTPS. Client Variables: Client variables pretty similar to session variables in most ways. The main difference is that they persist (where as session variables exist in memory & expire after a certain period). Storing client variables in the registry or a database is pretty much the same thing in terms of what we are discussing now - the key point is the values get stored on the server. Storing client variables in a cookie means that you actually send them all back & forth between the browser & server on each request. I think that is pretty much session & client scopes in a nutshell. > <quote>Because the session is being tied to the "Client" itself - i.e. the > actual browser. If you try the same thing but with a different browser on > the same machine it should work correctly.</quote> > > I tried it myself and did not get this to work, did anybody else? The only way I can see this happening is that you might have been passing CFID/CFTOKEN values through the URL. If I have a URL that looks like http://www.domain.com/index.cfm?CFID=XXXX&CFTOKEN=XXXXXXXX and I posted it to this mailing list - everyone who clicked the link would be the same client as far as CF server was concerned & pick up the same session variables because they are using the same PIN number. So if you are testing in two browsers in this way you are going to get the same problem. However if you clear the CFID/CFTOKEN off the link there is no way that your session in Netscape is going to be shared with your session in IE. > Can anyone elaborate on the following "particular client and > application and > that must be saved between user sessions" Client variables persist (as I mentioned before) so if I log into a site tha t supports them, then go away & come back a week later my session will be long gone, but my client variables should still exist. This makes client variables good for things like "Remember me" functionality or tracking when I last visited the site & how many times I've been to the site. In fact coldfusion even does some of the work for you by automatically providing client.hitCount, client.lastVisit & client.timeCreated. Client variables are application specific, so if I have one CF server with 3 apps on it I'll get unique values in my client scope for each application. hth Cheers Mark ------------------ Mark Stanton Technical Director Gruden Pty Ltd Tel: 9956 6388 Mob: 0410 458 201 Fax: 9956 8433 http://www.gruden.com --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
