-----------------------------------------------------
RSESSION - Session Management for Clusters That 
		   Support Failover with Allaire Cold Fusion
-----------------------------------------------------
Updated:  2/2/2001  This file contains thoughts and examples on 
the framework and some caveats to help you develop using Rsession.


Based upon some feedback from Jordan Clark <jordan@stockscape.com>, we 
made a modification to the default out-of-the-box behavior to Rsession
in version 1.2. 

Initially, we were using an initialization value of 0 for CFID.

Unique sessions are defined by the combination of the values of CFID
and CFTOKEN (which is a UUID - 35 character globally unique value).

In our initial application, an entertainment site, security of sessions 
was not a critical issue because the worst thing that can happen should
a user snarf another users session is that they could win prizes for
another user (*gasp!*).

Because of this, we made the decision to give "guest" users a CFID of 0
and registered users would be given a CFID of non-zero.  There was some
discussion about this on the BACFUG list:

Original Question:
http://mail.vfive.com/cgi-bin/ezmlm-cgi?1:msp:398:mfkooboldldeogcgobkn
My reply:
http://mail.vfive.com/cgi-bin/ezmlm-cgi?1:msn:398:mfkooboldldeogcgobkn

The short summary is that the following code is what we were using
to "register" a user:

<!--- seed the random function, create the users session and account information --->
<cfset Randomize(right(GetTickCount(), 5))>
<cfset CFID = RandRange(100000,999999)>

<!--- update their existing session with new login information --->
<cfquery name="qryUpdateSession" datasource="#request.dsn#">
  UPDATE tblLookupSession
  SET CFID = #CFID#
  WHERE CFID = #request.session.cfid#
  AND CFTOKEN = '#request.session.cftoken#'
</cfquery>

<!--- update session var and cookie to reflect new user ID --->
<cfset request.session.cfid = CFID>
<cfcookie name="CFID" value="#CFID#" expires="NEVER" domain=".backslap.com">

It's fairly straightforward - we're simply picking a random 6 digit number,
updating the users state information, updating their request.session value
for the rest of that page request, and updating their cookie to reflect the
change.

As Jordan pointed out though - for out-of-the-box behavior as a session 
framework, that is fairly insecure.  We have modified this behavior
in version 1.2 to select a random six-digit number as the default CFID 
rather than zero.  Our framework now mimics the functionality of Allaire's
session framework in 4.5 and should provide equal security.

<READ_THIS>
Of course, using a value that is "available" to the user (as in a COOKIE) should
never be a security mechanism since they could possibly hack it to gain 
unauthorized access to your site.  In _our specific case_, that was not
an issue and thus, our use of 0 as the default.

We heartily recommend upgrading to version 1.2 (only the Application.cfm 
is different) to provide additional security.
</READ_THIS>


----------------------------
Known Issues with CFLOCATION
----------------------------

One caveat about using this and CFLOCATION.  Similar to the issue with 
setting cookies on a page that uses CFLOCATION and the required workaround, 
there are also issues with using CFLOCATION and our state management
solution.  

Because state management is saved via a call in OnRequestEnd.cfm on every 
page request, you _must_ call OnRequestEnd.cfm (or at the very least 
rsession/session_save.cfm) prior to using CFLOCATION or you will lose any 
values set during that template:

<!--- save session and send them to the home page --->
<cfinclude template="rsession/session_save.cfm">
<cflocation url="home.cfm">
								
This is actually an advantage over standard Session management where there
is no possible way to execute a "save session" function prior to executing a 
CFLOCATION.  This means less hacking and more developing.

In the custom tag version of Rsession, you would instead need to call <cf_session_save>
to write the session to the database prior to CFLOCATION.




