Flash Cookies :: Yes my friend, feel the love

Flash cookies, technicaly known as "locally stored Shared Objects" are a very simple way to keep local, persistant data for the client. 

Especially in this day and age of needing to keep track of users on a site, basic browser cookies are good until the user deletes them. The nice thing about the Flash cookies is that they're not widely known about yet.  So, you're MUCH less likely to have your cookies deleted by the end user.  If you have to employ some type of "ban" on a particular user, a Flash cookie will probably go undetected by the would be offender.  But like every technology, the end users WILL find out about it and we'll be back to the same life as a browser based cookie;)

Ok, so how does it work?  Well, you create a variable and assign it the SharedObject reference with the getLocal(cookieName,[path]) method.  You need to provide a name for the cookie you're looking for, and with that said, you can see that you're able to have multiple cookies for a site (I would sure hope so!).  The "path" is optional and a bit confusing at times. The "Path" discussion is lengthy, so, I'll save that for after the example.

The most important method you'll want to remember is flush().  If you want your data persistant (saved), you have to call this method on the shared object:
_root.soVars.flush()
if you don't, your data will only exists for that session. For some applications, this is a good thing, like chat applications.

// Set assign the SharedObject "siteInfo" to _root.soVars
_root.soVars = SharedObject.getLocal("siteInfo");

// You can check for values by accessing the data object in the soVars object
if(_root.soVars.data.firstName == undefined)
{
   _root.soVars.data.firstName = txtFirstName.text;

   // Save your data
   _root.soVars.flush();
}

txtFirstName = _root.soVars.data.firstName;

WOW! That wasn't to bad at all!  I'll bet you rather liked that, eh? Show ain't over son.  Have a seat.

Path fun:
  path: An optional string parameter that specifies the full or partial path to the SWF file that created the shared object, and that determines where the shared object will be stored locally. The default value is the full path.

Now, that may *sound* nice, but it's not a great explanation ;)

First, while we're discussing "path", you'll need to know where they're being stored. On a windows machine, it's:
"C:\Documents and Settings\userAccount\Application Data\Macromedia\Flash Player"
In this folder you'll see all the web sites that have saved Flash cookies as well as programs (IE: FireworksMX, DreamWeaverMX). The actual cookie is an SOL file.

If you don't specify path, Flash assumes the full path (IE: "www.acmewebworks.com/apps/myMovie.swf" OR "/documents and settings/my documents/CookieTest.swf").

Local Drive/CDROM usage:
The path has to go to the SWF level, not just the folder in which it sits (look up at last example).  If you want other SWF's to access THIS SWF's cookies, you can't do it.  Only SWF's loaded from a web server can do this and they have to be on the same domain.

If you're doing a CDROM presentation, you'll want to leave the path blank, as the Flash player will take care of creating a reference for it automatically.  This is perfect because you could never be sure the user's CDROM drive letter/location.

If you have to access the SO with a physical location, for some reason, on the harddrive rather than a web URL, you leave of the drive letter, start with a forward slash and path it out to the exact file name.  If you dont' include the file name, it won't work:
_root.soVars = SharedObject.getLocal("siteInfo", "/Documents and Settings/jgrden/My Documents/CookieTest.swf");

URL usage:
The path can be relative to the folder, unlike the local drive usage.  So, if you have a myMovie.swf sitting in a "movies" folder, it could look like this:
_root.soVars = SharedObject.getLocal("siteInfo", "/movies/" or "http://www.acmewebworks.com/movies/");

If you want other SWF's to use this cookie information, set the path to a relative folder path and don't supply the name of the SWF. 

NOTE: The Flash docs say that this will allow any other SWF on the same domain to get to this cookie - that's not true.  The other SWF's that have to reference that cookie must be in either the same folder OR in a child folder underneath the container folder.  Say what?  like so:

your SWF is in folder "a" and creates a cookie called "userInfo":
soVars = SharedObject.getLocal("userInfo", "/a/");

/a/myMovie.swf

For any other SWF on your site to be able to get to the cookie in "a", they have to either be in the same folder OR in a child folder like so and use the same path parameter in the getLocal method:
soVars = SharedObject.getLocal("userInfo", "/a/");

/a - yes
/a/aa - yes
/a/aa/aaa - yes
/b - no
/b/bb - no
/a/aa/aaa/aaaa - yes

So, if you want your cookie available to the entire site, make sure it's at the root level:
soVars = SharedObject.getLocal("userInfo", "/");

Now, the cool thing is that they've included an onStatus event handler which will return information when you try to write (flush()) to the cookie.  It will return either "error" or "status" based on whether it successfully wrote the data to the cookie or not IF the user has set the local storage settings to zero.

Here is a code snip from a sample file you can download.  It's Flash 2004, so you'll have to have 2004 to open the file.

//---------------------------------------------------------------->
//------------[flash cookies - ActionScript 2.0]-------------------->

// create 2 dynamic textboxes on your stage, call one of them txtFirstName and the other txtInfo
// Make txtInfo a multiline textbox

var soVars:Object = SharedObject.getLocal("testInfo", "/john");

soVars.onStatus = function(infoObj)
{
     // "error" is returned when the user has set the local file storage size to zero
     // "status" is returned when Flash was able to ask permission to save the cookie information
     // and the user said "allow"
     // this event is event invoked if there wasn't any issue with writing to the cookie.
     txtInfo.text += "status: " + infoObj.level + "\n";
}

// soVars will be null if the directory/path cannot be located.
txtInfo.text += "soVars: " + soVars + "\n";

if(soVars.data.firstName == undefined)
{
     // check to see if the data is available.  If not, write it
     soVars.data.firstName = "John";
     soVars.flush();
}

txtFirstName.text = soVars.data.firstName;

for(x in soVars.data)
{
      // loop through all the elements of the object
     txtInfo.text += soVars.data[x] + "\n";
}
//-------------------[end]----------------------------------------->

Download FLA

Well, I hope that helps put Flash cookies in perspective. I have to admit that working in MX, I found that working with cookies was EXTREMELY unpredictable.  One minute the cookies worked, the next, they didn't.  It was like voo doo and once I got it to actually work, I placed a ban on anyone else on the team to touch that code under penalty of a stiffly worded email ;)  With Flash 2004, it worked and acted as though it should work and act.  I did identical tests on MX and 2004 and MX gave me a ton of problems where as 2004 worked the first time around.  I'm assuming that either 1) i was not aware of something obvious that cause MX to have such problems 2) there is a bug in the MX player concerning cookies.

Any questions?  Send me an email: [email protected]