Desparate!!!! Need someone to look at my code and figure out the problem!

You've got to set this.setClientCookies=true in the Application.cfc, or pass the CFID/CFTOKEN/JSessionID in every URL and form post. On Wed, Jan 7, 2009 at 7:26 PM, Rick Faircloth <Rick@whitestonemedia.com>wrote: ----- Excess quoted text cut - see Original Post for more -----

Hi, Brian!  You hit the nail right on the head! All I had to do was set "this.ClientCookies = true" and the session variables are flying everywhere! But why was this working on my local setup?  Everything is the same?  Does it have to do with a multi-site setup on my VPS, perhaps? And why do I need to have cookies turned on?  Do session variables interact with them?  I usually turn them on, but since this is the way the first example application.cfc I saw was set up, I copied the settings for the most part. What's your charge or where's your wish list? Yay!  I can sleep tonight!  :o) Rick ----- Excess quoted text cut - see Original Post for more -----

> But why was this working on my local setup?  Everything > is the same?  Does it have to do with a multi-site setup > on my VPS, perhaps? Presumably, you have some other CF app which is setting cookies, so your app doesn't have to. > And why do I need to have cookies turned on?  Do session > variables interact with them?  I usually turn them on, > but since this is the way the first example application.cfc > I saw was set up, I copied the settings for the most part. HTTP is a stateless protocol. It doesn't have any built-in mechanism to keep track of previous page requests, or anything like that. You request a page, you get a response, that's it. You request another page, that is a completely separate transaction and the web server doesn't associate that with your previous page request. So, to provide state management - the ability for your application to remember logins and other session-specific data - CF has to have some sort of session token that it can track from one request to the next. This token can either be stored in a cookie, or it can be embedded within each HTTP request using form or URL data. But it has to be one or the other. Generally, developers use cookies for session tokens, because it's a lot easier to set the cookie once, then to make sure that every link, form post, redirect, Javascript location assignment, etc, contains the token. So, yes, cookies are in that sense a prerequisite for session management. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!

Well, after 10 years with CF, I learn something I should have learned with CF 4.5. I thought cookies were on the hard drive and session variables were in memory only.  I figured that's why there were separate settings for client management and session management all this time. Concerning "another app" setting cookies... I had "this.setClientCookies = false" specifically set in this app. Would another app on my local machine still be able to set cookies that would affect this app?  There's not another app with the same application name... ----- Excess quoted text cut - see Original Post for more -----

On Wed, Jan 7, 2009 at 5:19 PM, Rick Faircloth <Rick@whitestonemedia.com>wrote: > Well, after 10 years with CF, I learn something I should > have learned with CF 4.5. > > I thought cookies were on the hard drive and session variables > were in memory only.  I figured that's why there were separate > settings for client management and session management all this time. > they are.  you need something on the server and something on the client in order to maintain state across http requests.  if it was just on the server, how would the server identify the browser?  if it was just in the browser, how would the server know what to do with those values?  it needs to be on both.  session is in memory on the server (versus in the database or registry for client vars).  on the client, it can either be in a cookie or passed in the URL or form vars... but it needs to exist on the client for each request. -- I have failed as much as I have succeeded. But I love my life. I love my wife. And I wish you my kind of success.

Well, that makes a lot of sense...thanks, Charlie! (I'm just glad Wil didn't see this.  I'd never hear the end of it...) Rick ----- Excess quoted text cut - see Original Post for more -----

Take a look at the headers with Firefox's LiveHTTPHeaders extension. You can see the cookies come and go. Mike out the problem! On Wed, Jan 7, 2009 at 5:19 PM, Rick Faircloth <Rick@whitestonemedia.com>wrote: > Well, after 10 years with CF, I learn something I should have learned > with CF 4.5. > > I thought cookies were on the hard drive and session variables were in > memory only.  I figured that's why there were separate settings for > client management and session management all this time.

Thanks for the tip, Mike! Rick ----- Excess quoted text cut - see Original Post for more -----

> I thought cookies were on the hard drive and session variables > were in memory only.  I figured that's why there were separate > settings for client management and session management all this time. No, both client and session management rely on cookies (by default) to be associated with a specific browser. The difference is that session data is stored in memory, and client data is stored somewhere else (database, registry, or in additional cookies sent to the client). > Concerning "another app" setting cookies... > I had "this.setClientCookies = false" specifically set in this app. > > Would another app on my local machine still be able to set cookies > that would affect this app?  There's not another app with the same > application name... If you have two different CF applications on a machine, and both of them use session management, and both are within the same domain, and you visit both of them, your browser will only receive one set of cookies. Each application will associate different session data with those cookies. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!

you don't "need" to have cookies turned on.  as brian said, either turn 'em on or pass the CFID & CFTOKEN variables in each request (either via URL or form). session vars rely on the presence of the CFID and CFTOKEN vars to maintain state.  this is either done via a cookie, or by passing those vars explicitly from request to request. On Wed, Jan 7, 2009 at 5:02 PM, Rick Faircloth <Rick@whitestonemedia.com>wrote: ----- Excess quoted text cut - see Original Post for more -----

Does your local box use J2EE sessions? If so they don't use the CF client cookies, they use a jsessionid cookie. mxAjax / CFAjax docs and other useful articles: http://www.bifrost.com.au/blog/ ----- Excess quoted text cut - see Original Post for more -----

No, I have that unchecked in the admin. Are jssession cookies preferable, or does it matter? > Does your local box use J2EE sessions? If so they don't use the CF > client cookies, they use a jsessionid cookie. > > mxAjax / CFAjax docs and other useful articles: > http://www.bifrost.com.au/blog/ > >

> Are jssession cookies preferable, or does it matter? Well, it depends. If you're referencing CFID and CFTOKEN in your code, you'll want to stick with CF's default cookies. If you're not, the advantages of using J2EE session management are that the cookie is non-persistent - it's closed when the browser is closed - and that it's a UUID value which is significantly harder to guess (or more accurately, identify by a brute-force attack) than two large integers. But you can use a UUID for CFTOKEN also, if you like, and you can rewrite CF's default cookies to be non-persistent. The one advantage of J2EE session management that you can't get with CF's default cookies is if you'd like to integrate Java servlets or JSP pages within a CF application (or CF pages within a J2EE web application). Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!

Thanks for the info, Dave! Rick ----- Excess quoted text cut - see Original Post for more -----