When you setclientcookies to "no" then you must append every link you have (e.g. <a 
href>, <cflocation>, location.href) with the cfid and cftoken.  If you don't, then CF 
will lose track of the person's session.

Also, that posting from the forums is wrong.

----- Original Message -----
From: Susan Hamilton-Allen <[EMAIL PROTECTED]>
Date: Friday, September 6, 2002 3:53 pm
Subject: RE: Client Vars again

> 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'tknow 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'trealize 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 
> occurrencein 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 
> passingyour 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 
> runningthe 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'relooking 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 
> win2kserver.
> 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 
> samething (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 
> couldjust
> > 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

Reply via email to