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
> 
> 
> 







______________________________________________________________________
Structure your ColdFusion code with Fusebox. Get the official book at 
http://www.fusionauthority.com/bkinfo.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