One of the things I’ve always thought was missing from Flash was access to a browser’s cookies. I can understand the argument that cookie access is unnecessary for sites that are primarily flash based.  After all Flash’s Local Shared Objects make persisting data across sessions or page views fairly painless.  However for hybrid sites where the server passes information to the browser via cookies a developer must jump through a few hoops to get any important data sent from the server via a cookie into Flash.

Current Techniques

Perhaps the two most popular options are using Javascript to read cookie values and pass them to a swf via Flash’s ExternalInterface API or (shudder) fscommands.  Another alternative is to completely forgo cookies as a transport method and create a Flash specific interface to exchange what would otherwise be sent via cookie.  These techniques, and others, make sense if your site or app is primarily Flash based, but come off less than perfect for a hybrid site.  For a hybrid site, special code has to be written to accommodate a perceived shortcoming in a single interface.  This seems wasteful, adding unnecessary dependencies for a page or application to function.  Wouldn’t it be better if Flash could access cookies sent from the server all on its own?

Getting Access to Cookies

The first thing to understand is that cookies are passed to and from a webserver as a part of the HTTP request and response headers.  So all we need to have access to cookies inside a swf is something that can access HTTP headers.  The likely candidates are the URLLoader, URLRequest and URLRequestHeader classes.  Whenever you use the URLLoader (or other classes like it) Flash automatically passes any relevant cookies to the server.  The cookies are drawn from either IE on Windows, or Safari on the Mac (not sure about Linux), and happens entierly behind the scenes.  Now we can use the URLRequest and URLRequestHeader classes to insert custom header information, including cookies, into a call made via the URLLoader, but sadly, we doomed to disappointment because the URLLoader does not provide us a way to access the raw header information, and that is the goal.  So this isn’t really a solution, I mention it only because this seems to be where most Actionscripters start. However, a lesser talked about class will give us the access we need.

Introducing Sockets

The Socket class was introduced in Actionscript 3.0 and provides access to the raw data sent from the server.  We can use this lower level access to retrieve the cookie data sent from the server by parsing the HTTP Response headers. Here is more or less how it works:

First create an instance of a Socket class and add listeners for its complete event (this isn’t quite pseudocode but its not exactly valid either).

protected var sock:Socket = new Socket();
sock.addEventListener(Event.COMPLETE, onSocketComplete);

When the complete event is dispatched (or the first progress event if you’re in a hurry) you are ready to retieve the response headers and parse out the cookie data.  First read the content of the socket to a string, then close the socket. Its served its purpose.

var response:String = sock.readUTFBytes(sock.bytesAvailable);
sock.close();

Response headers are essentially a specially formatted string and are seperated from the response body by two full carriage returns.  Above, we stored the content of the socket request in the response variable. Split that on the double carriage return. The first item in the array will be the response headers.

var headers:String = response.split("\r\n\r\n")[0];

The actual headers are sparated by a single carriage return. We’ll split the headers into their own array.

var headerArray:Array = headers.split("\r\n");

Now its a simple matter of looping over the array and looking for the appropriate header. A header is formatted as a name value pair seperated by a colon.  So we’ll loop over headerArray split each header into its name value pair, and check to see if its name matches the “Set-Cookie” response header. Whenever we find a match, we have found a cookie and we’ll save it in an array set aside for that purpose.

var cookies:Array = new Array();
for(var i:int = 0; i<headerArray.length; i++){
    var tmp:Array = headerArray[i].split(":");
    var name:String = tmp[0];
    var value:String = tmp[1];
    if(name == "Set-Cookie"){
        cookies.push(value);
    }
}

And there you go! You have just retrieved all the cookie data from an HTTP response receieved from a Socket.  From this point it should be a simple matter of parsing the content of the cookie array for the data you need.

There is a lot more you can do with Sockets but those are things beyond the scope of this article.

There’s Still Something Missing

Wait what? We can get the cookie data from the server, so what more do we need? Sadly, the method I’ve described only allows us to grab the cookies sent from the server.  If some Javascript sets a cookie client-side the server is not going to be aware of it until a new HTTP request is made (e.g. refresh the page, request new content, etc.). So for a swf to know about the cookie, we’re left with making a throw-away request to the server via a URLLoader (or some other class that has native, behind the scenes access to a browser’s cookies), then making a new request to get the updated cookies via the Socket method.  Of course, this begs the question, how will the swf know to get updated cookies?  Sadly, the better solution is to, once again, rely on the ExternalInterface API to pass the updated data to the swf.

Hopefully, a future version of the player will open these doors a little wider and Flash will finally have access to the browser’s cookies.

Be Sociable, Share!

•