Yes.  Unfortunately although the value of the cookie is deleted, the key in the cookie struct remains until the page is refreshed - it needs to send headers out before the key is deleted - which means you can't delete the cookies in the same piece of code as cfapplication.  ColdFusion will then take your empty cookie value and makes a session with a blank CFID/CFTOKEN, which is a big security problem.

I have a pretty pathetic solution, which is to test if the cookie exists, delete them, redirect them to a HTML page (since we've now done a refresh, the cookies are gone) and do a meta refresh back to index.cfm  Unfortunately this isn't a complete solution for us since we have non-browser clients that access the site for whom this won't work.

Thanks

KNOTT, Brian wrote:
Can't you check for the existance of cookies and delete if they exist.

Brian

  
-----Original Message-----
From:	Laszlo Simity [SMTP:[EMAIL PROTECTED]]
Sent:	Friday, 14 May 2004 10:12
To:	CFAussie Mailing List
Subject:	[cfaussie] RE: Big MX Problems

Yes, we've added that thanks.  Unfortunately, we will have an existing
user base that will have CFID/CFTOKEN's when we release CFMX due to us
parcelling this information out in CF5.  

As I say, it does work for new users.  That is to say, if you have IE,
clear all your cookies, and go to our site, everything will work as
expected.  The problem is users that have a cookie (from when we were
using CF5) and will go to our site, when CFMX is released.

Darren Tracey wrote:


	To make sure that CF doesn't write CFID/CFTOKEN cookies, all you
should have to do is add 
	 setclientcookies="No"
	in your <CFAPPLICATION ...> tag.
	Have you already tried this?
	Did it work?
	 
	Regards
	 
	Darren Tracey

		-----Original Message-----
		From: Laszlo Simity [ <mailto:[EMAIL PROTECTED]>]
		Sent: Friday, 14 May 2004 9:41 AM
		To: CFAussie Mailing List
		Subject: [cfaussie] Big MX Problems
		
		
		Hi,
		
		We're just trying to migrate to MX from 5.  We're having
some problems with session management.
		
		Our site does not use cookies for session management -
rather a unique identifier (not the CFID/CFTOKEN pair) is sent through the
URL.  Now, in 5, Coldfusion would still set (probably our own fault here,
but this is beside the point :)), a cookie with the CFID/CFTOKEN.  
		
		What we would do is say:
		
		Is there a URL identifier?
		yes:
		Do some work here to make sure CfApplication will know it's
an existing session
		no:
		Set the cookies to blank
		Call cfapplication - which will create a new CFID/CFTOKEN
and session
		
		This still works to an extent.  We no longer generate
cookies, and therefore for new users with a fresh browser, this still
works.  However, if you already have a CFID/CFTOKEN set in your browser
from our site, MX creates a session in the "no" case above, to the values
in your cookie.  What's worse is that if the cookie is blank, it creatse a
session with a blank CFID/CFTOKEN pair.  What this means is that in
testing, we had the entire company using one session (as we all had
CFID/CFTOKEN cookies that were blank).  This seems like a pretty serious
bug at least.
		
		Obviously as some sort of "release task", we need to delete
these cookies from peoples' browsers.  Or better yet, have ColdFusion
ignore blank cookie values - or preferably cookies totally in the call to
cfapplication.  I am unable to find any documentation that suggests
anything like this is possible.  
		
		Whilst I can test for the cookie key existence, then
redirect to a page that deletes the cookies and meta refreshes back to the
index.cfm, we have non-browser http clients that access our site via form
submission, so this isn't necessarily an option.
		
		Anyone have an ideas?
		
		Thanks
		---
		You are currently subscribed to cfaussie as:
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
		To unsubscribe send a blank email to
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> 
		MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
		<http://www.mxdu.com/> + 24-25 February, 2004 

	---
	You are currently subscribed to cfaussie as:
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
	To unsubscribe send a blank email to
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> 
	MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
	<http://www.mxdu.com/> + 24-25 February, 2004 

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


-----------------------------------------------------------------------------------

The contents of this message are the views of the Author and do not necessarily reflect the views of SUNCORP-METWAY LTD  ABN 66 010 831 722.

The content of this e-mail, including attachments is a confidential communication between the Suncorp Group and the intended addressee. Any unauthorised use of the contents is expressly prohibited. If you have received this e-mail in error please contact the sender immediately and then delete the message and any attachment(s).

suncorp.com.au


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

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

Reply via email to