If I read back thru the thread correctly (luv them archives, Michael), the setclientcookies=no statement you just mentioned would cause you to lose state if you aren't explicitly passing cfid and cftoken via every url link of any kind.
I've never tried it but I believe that a cflocation with addtoken=''yes'' in such a configuration would result in the creation of a new key pair per cflocation statement. You'd need to <cflocation url=blah.cfm?CFID=#url.CFID#&CFTOKEN=#url.CFTOKEN# addtoken="no"> --------------------------------------- Matt Robertson [EMAIL PROTECTED] MSB Designs, Inc., www.mysecretbase.com --------------------------------------- ---------- Original Message ---------------------------------- from: Susan Hamilton-Allen <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] date: Fri, 6 Sep 2002 16:53:15 -0500 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 Programmer Pfingsten Publishing, L.L.C. Seven Hills, OH 44131 -----Original Message----- From: Bryan Love [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 ...cookies="no" then you MUST pass CFID and CFTOKEN in the url string. Otherwise you lose your session with every request. This has been the source of many problems I've seen. Many people don't realize that <cfapplication> sets cookies and so they wonder why their session persists even after the browser closes. If you let <cfapplication> set cookies you must replace them with temporary ones or they will still be there days, weeks, months later. That can cause a problem debugging if you don't realize they exist... +-----------------------------------------------+ Bryan Love Macromedia Certified Professional Internet Application Developer Database Analyst TeleCommunication Systems [EMAIL PROTECTED] +-----------------------------------------------+ "...'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: Susan Hamilton-Allen [mailto:[EMAIL PROTECTED]] Sent: Friday, September 06, 2002 2: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, 2002 4:11 PM I have two servers where I have installed my web pages. On one machine it works fine. On the other, the client variables seem to not be saved. I have set the client variables to be saved in the database on both machines. On the one that doesn't work, it seems like when I submit my login form, the next page doesn't know about the client variables. It also seems to generate a new row in my database. It's almost acting like it doesn't know who it is so it's generating every single time. I've tried setting it to registry and cookie and have the same results. As it turns out the "bug" was that CFMX changed the default attribute setting on the cflocation tag. It used to default to addtoken="no", but now defaults to addtoken ="yes". Because we have a snippet of code that prevents session hijacking by removing the CFID & CFTOKEN from the url line, this caused every CFLOCATION to increment the CFID and actually lose state. Small CF change, but big problem for us until we were able to figure it out. Everything was back to normal when we added addtoken="no" to each occurrence in the site. Susan Hamilton Allen Web Programmer Pfingsten Publishing, L.L.C. Rock Run Center, Ste. 280 5700 Lombardo Center Dr. Seven Hills, OH 44131 phone: 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 your CFID and CFTOKEN to the server. The only way that can happen is via COOKIE or URL. Compare the COOKIE and URL values for CFID and CFTOKEN and ensure they are the same. Perhaps one of them is getting changed and that is throwing you off... Also, be sure to delete all cookies on the test machine(s) before running the test and comparing the results to those on other test machine(s). +-----------------------------------------------+ Bryan Love Macromedia Certified Professional Internet Application Developer Database Analyst TeleCommunication Systems [EMAIL PROTECTED] +-----------------------------------------------+ "...'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: 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 is specified - CFID seems to be an exception to the standard scoping rule since it can be found without scoping even when it doesn't exist in the url, form, or variables scope. Anyway, make sure they are all the same and if not then make sure you're looking up the right one. +-----------------------------------------------+ Bryan Love Macromedia Certified Professional Internet Application Developer Database Analyst TeleCommunication Systems [EMAIL PROTECTED] +-----------------------------------------------+ "...'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: Susan Hamilton-Allen [mailto:[EMAIL PROTECTED]] Sent: 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 -----Original Message----- From: Bryan Love [mailto:[EMAIL PROTECTED]] 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 Analyst TeleCommunication Systems [EMAIL PROTECTED] +-----------------------------------------------+ "...'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: Susan Hamilton-Allen [mailto:[EMAIL PROTECTED]] Sent: Friday, September 06, 2002 1:13 PM To: CF-Talk Subject: RE: Client Vars again DB: SQL Server 2000; Client OS: win2k; intranet app; single server win2k server. Application.cfm set for clientmanagement="Yes", clientstorage=the SQl data source, which was successfully registered w/in CF. Using <cflocation addtoken="yes."> First we thought everything was great; then we ran the app on another pc in the office. Client variables were not writing to the db, although they were writing successfully on the 2 developers' machines. Checked browser versions, os versions, couldn't find any links to identify where the problem was. Again, these two machines were writing the client var strings correctly to the database. Read on MM site that addtoken="yes" will cause CFID to increment, which we did find to be true for SOME of the pcs. Changed addtoken to no; the machines they didn't carry the variables successfully now did not write to the database at all. My machine was the only one of the 5 that kept working no matter what. Uninstalled CFMX, reinstalled, changed addtoken to "yes," and now my machine did the same thing (CFID incrementing, one row per write to the client state). No other machines were able to write to the db, although they "sometimes" seemed 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 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? Can you consistently set a cookie and across page requests read it properly? DRE -----Original Message----- 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 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 rows being written for each write to the client state, with incremented CFIDs. We changed to "addtoken=no" and all of a sudden only one user could write to the database at all. We tried, as you have, to find a common denominator to explain the inconsistent behavior among 5 machines; browser versions, os versions, etc. After much trial and error, I uninstalled CFMX, reinstalled, and are now using cookies instead. Hope you have better luck than us; like I said, take a look at your db and you may see the same symptoms. Susan Hamilton Allen Web Programmer Pfingsten Publishing, L.L.C. Seven Hills, OH 44131 -----Original Message----- 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 works on ALL browser > combinations? > > This is what we're doing... > Client vars stored in a DB > Using the usual code to kill a session on close of the browser CFMX, > SQL Server 7 Testing on most combinations of browser. > > Trying to figure out what's going wrong wouldn't be so bad if we could just > have some consistency in the way it's going wrong. We have... Logging > in on 2nd, 3rd, 4th, 5th try instead of the 1st Not able to log out, > trying both reseting the client vars back to their original state and > deleting them altogether Having to change a cflocation to a > window.location to get it to log in on IE5 (don't ask) > > I've just said to the guy I'm building it with, "shall we pass cfid > and cftoken in all the links and redirects, see if that cures it". > What does everyone else think. It's not the easiest thing to debug > something that you > can't reliably replicate :O( > > > Adrian Lynch > Thoughtbubble Ltd > ---------------------- > United Kingdom > http://www.thoughtbubble.net > Ph: +44 (0) 20 7387 8890 > ---------------------- > The information in this email and in any attachments is confidential > and intended solely for the attention and use of the named > addressee(s) . Any views or opinions presented are solely those of the > author and do not necessarily represent those of Thoughtbubble. This > information may be subject to legal, professional or other privilege > and further distribution of it is strictly prohibited without our > authority. If you are not the intended recipient, you are not > authorised to disclose, copy, distribute, or > retain this message. Please notify us on +44 (0) 20 7387 8890 > > > ______________________________________________________________________ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
