Using AS3 SharedObject in Flash (Flash Cookies)

[Silviu]

This tutorial will teach you how to use the AS3 SharedObject Class to store small amounts of data on the end user's machine. This stored data could be used to store a game's highscore, a user's login data, or any other information that you need to be remembered when the user visits your Flash movie again.

Shared Objects are very similar to cookies on a browser, however, they are not stored with the rest of your browsers cookies and are not deleted when the user deletes the regular cookies, instead they are completed managed by the Flash Player.

Following this tutorial requires you only to know the basics of AS3 variables.

This tutorial is divided into the following sections:

The getLocal() method.

Storing Data.

Reprieving Data.

Deleting Data.

Practical Example.

Using the getLocal() Method

The getLocal() method is the most fundamental aspect of the SharedObject Class. Unlike the majority of other ActionScript classes, you do use the new keyword to create your instance of this class, instead you use the getLocal() method. This methods checks if there is an existing instance of this object stored, and if not, it creates that object - otherwise it simply retrieves the existing object for you to manipulate.

This method is used in the following generalized code format:

var myVariableName:SharedObject = SharedObject.getLocal("mySharedObjectID");

The variable name is the reference you would use inside your program to refer to your Shared Object, while the Shared Object ID is the ID to be used only to store and retrieve that object from the Flash Player memory.

Even though you might want to store more than one piece of information, you can only use one Shared Object to store this data. The object can have as many data properties in it as long as the size of your Shared Object does not exceed the size limit set by the end user. This option is configured by the end user through his Flash Player settings. The default maximum size for Flash Player stored data is a 100KB - which is way more than what you would need for storing simple stuff like user data.

To start with our tutorial code, use the following to create your first Shared Object:

var mySharedObject:SharedObject = SharedObject.getLocal("republicofcode");

The following section will show you how to store data in this object.

Basic Usage of the SharedObjects Class

In order for your data to be stored inside a Shared Object the following must be done:

Create an instance of the SharedObjects Class using the getLocal() method.

Store data inside the SharedObjects instance.

Write the ShareObjects instance into the player using the flush() method.

We have talked about the first step earlier, you simply create your Shared Object using the getLocal() method this way:

var mySharedObject:SharedObject = SharedObject.getLocal("republicofcode");

That should create our SharedObject for us. To add new data to this Shared Object we use the .data property to store whatever data we want in this object. For example, we are going to store the first and last name of the user, each in a separate data container:

var mySharedObject:SharedObject = SharedObject.getLocal("republicofcode");
mySharedObject.data.firstName = "John";
mySharedObject.data.lastName = "Doe";

This data is now attached to the Shared Object currently running in the movie, to store this data in the Flash Player and then to be able to retrieve it for future sessions we need to use the flush() method this way:

var mySharedObject:SharedObject = SharedObject.getLocal("republicofcode");
mySharedObject.data.firstName = "John";
mySharedObject.data.lastName = "Doe";
mySharedObject.flush();

This will store the data in the Flash Player.

Retrieving Data Stored in a SharedObject

Retrieving the data stored as in a Shared Object is very similar to the process for storing this data. This requires only two steps, the first is retrieving the actual Shared Object by using the getLocal() method and then retrieving the data through the data property.

We have earlier said that using the getLocal() method is a special process that attempts to check if your Shared Object exists before attempting to create one. If that object does exist, then it simply retrieves it and stores it in your variable:

var mySharedObject:SharedObject = SharedObject.getLocal("republicofcode");

Once you retrieve the SharedObject, you can dig up the content within it by directly accessing the information through the data property:

var mySharedObject:SharedObject = SharedObject.getLocal("republicofcode");
trace(mySharedObject.data.firstName);
trace(mySharedObject.data.lastName);

If you simply paste this code and test your movie your test window should output the names we specified earlier.

Deleting Data

If for some reason you want to delete all the data stored in your Shared Object, you can do that by using the clear() method:

var mySharedObject:SharedObject = SharedObject.getLocal("republicofcode");
mySharedObject.clear();

Practical Example

The code below shows you an example similar to the one shown at the top of the page where the position of a dragged object is stored for future sessions. In real life examples your code should first deal with the situation where no data is stored in your Shared Object as that would be the default position for most users.

In order to test this code you need to create a movie clip on stage and assign the instance name logo_mc to it:

var mySO:SharedObject = SharedObject.getLocal("republicofcode");
logo_mc.x = mySO.data.my_x;
logo_mc.y = mySO.data.my_y;
if (!mySO.data.my_y) {
logo_mc.x = 150;
logo_mc.y = 100;
}
logo_mc.addEventListener (MouseEvent.MOUSE_DOWN, onDown);
function onDown (e:MouseEvent):void {
var my_mc = e.target;
my_mc.startDrag ();
}
logo_mc.addEventListener (MouseEvent.MOUSE_UP, onUP);
function onUP (e:MouseEvent):void {
logo_mc.stopDrag ();
mySO.data.my_x = logo_mc.x;
mySO.data.my_y = logo_mc.y;
mySO.flush ();
}
logo_mc.buttonMode=true;

You can learn more about conditionals and event handing in AS3 by reviewing our tutorials on these topics.

This concludes our tutorial. I hope that you found it helpful. Feel free to post any questions you have at the

Sursa: republicofcode.com

In adaugare, niste lucruri la fel de interesante:

evercookie -- never forget.

DESCRIPTION

evercookie is a javascript API available that produces

extremely persistent cookies in a browser. Its goal

is to identify a client even after they've removed standard

cookies, Flash cookies (Local Shared Objects or LSOs), and

others.

evercookie accomplishes this by storing the cookie data in

several types of storage mechanisms that are available on

the local browser. Additionally, if evercookie has found the

user has removed any of the types of cookies in question, it

recreates them using each mechanism available.

Specifically, when creating a new cookie, it uses the

following storage mechanisms when available:

- Standard HTTP Cookies

- Local Shared Objects (Flash Cookies)

- Silverlight Isolated Storage

- Storing cookies in RGB values of auto-generated, force-cached

PNGs using HTML5 Canvas tag to read pixels (cookies) back out

- Storing cookies in Web History

- Storing cookies in HTTP ETags

- Storing cookies in Web cache

- window.name caching

- Internet Explorer userData storage

- HTML5 Session Storage

- HTML5 Local Storage

- HTML5 Global Storage

- HTML5 Database Storage via SQLite

TODO: adding support for:

- Caching in HTTP Authentication

- Using Java to produce a unique key based off of NIC info

Download: http://samy.pl/evercookie/evercookie-0.4.tgz

evercookie is written in JavaScript and additionally

uses a SWF (Flash) object for the Local Shared Objects and

PHPs for the server-side generation of cached PNGs and ETags.

v0.4 BETA, released 10/13/2010

download source here

Or get it from github: http://github.com/samyk/evercookie

FAQ

What is the point of evercookie?

Evercookie is designed to make persistent data just that, persistent. By

storing the same data in several locations that a client can access, if

any of the data is ever lost (for example, by clearing cookies), the data

can be recovered and then reset and reused.

Simply think of it as cookies that just won't go away.

PRIVACY CONCERN! How do I stop websites from doing this?

Great question. So far, I've found that using Private Browsing

in Safari will stop ALL evercookie methods after a browser restart.

What if the user deletes their cookies?

That's the great thing about evercookie. With all the methods available,

currently thirteen, it only takes one cookie to remain for most, if not all,

of them to be reset again.

For example, if the user deletes their standard HTTP cookies, LSO data,

and all HTML5 storage, the PNG cookie and history cookies will still

exist. Once either of those are discovered, all of the others will

come back (assuming the browser supports them).

Why not use EFF's Panopticlick?

Panopticlick is an awesome idea, however the uniqueness really only

helps in consumer machines and typically not systems running in a

business or corporation. Typically those systems are virtually

identical and provide no difference in information where a home

user's laptop would. Evercookie is meant to be able to store the

same unique data a normal cookie would.

Does this work cross-browser?

If a user gets cookied on one browser and switches to another browser,

as long as they still have the Local Shared Object cookie, the cookie

will reproduce in both browsers.

Does the client have to install anything?

No, the client simply uses the website without even knowing about the

persistent data being set, just as they would use a website with standard

HTTP cookies.

Does the server have to install anything?

The server must at least have access to the JavaScript evercookie file.

Additionally, to use Local Shared Object (Flash Cookies) storage, the

evercookie.swf file must be present, and to use the auto-generated PNG

caching, standard caching and ETag storage mechanisms, PHP must be

installed and evercookie_(png|etag|cache).php must be on the server.

All of these are available in the download.

Is evercookie open source?

Yes, evercookie is open source. The code is in readable format without

any obfuscation. Additionally, the PHP files are open source as is the

FLA (Flash) code used to generate the SWF Flash object. You can compile

the Flash object yourself or use the pre-compiled version (evercookie.swf).

How does the PNG caching work?

When evercookie sets a cookie, it accesses evercookie_png.php with a special

HTTP cookie, different than the one used for standard session data. This

special cookie is read by the PHP file, and if found, generates a PNG file

where all the RGB values are set to the equivalent of the session data to

be stored. Additionally, the PNG is sent back to the client browser with

the request to cache the file for 20 years.

When evercookie retrieves this data, it deletes the special HTTP cookie,

then makes the same request to the same file without any user information.

When the PHP script sees it has no information to generate a PNG with, it

returns a forged HTTP response of "304 Not Modified" which forces the web

browser to access its local cache. The browser then produces the cached

image and then applies it to an HTML5 Canvas tag. Once applied, evercookie

reads each pixel of the Canvas tag, extracting the RGB values, and thus

producing the initial cookie data that was stored.

How does the Web History storage work

When evercookie sets a cookie, assuming the Web History caching is enabled,

it Base64 encodes the data to be stored. Let's assume this data is "bcde"

in Base64. Evercookie then accesses the following URLs in the background:

google.com/evercookie/cache/b

google.com/evercookie/cache/bc

google.com/evercookie/cache/bcd

google.com/evercookie/cache/bcde

google.com/evercookie/cache/bcde-

These URLs are now stored in history.

When checking for a cookie, evercookie loops through all the possible Base64

characters on google.com/evercookie/cache/, starting with "a" and moving up,

but only for a single character. Once it sees a URL that was accessed, it

attempts to brute force the next letter. This is actually extremely fast

because no requests are made to theserver. The history lookups are simply

locally in JavaScript using the CSS History Knocker. Evercookie knows it has

reached the end of the string as soon as it finds a URL that ends in "-".

USAGE

<script type="text/javascript" src="jquery-1.4.2.min.js"></script>
    <script type="text/javascript" src="swfobject-2.2.min.js"></script>
    <script type="text/javascript" src="evercookie.js"></script>

    <script>
    var ec = new evercookie(); 

    // set a cookie "id" to "12345"
    // usage: ec.set(key, value)
    ec.set("id", "12345"); 

    // retrieve a cookie called "id" (simply)
    ec.get("id", function(value) { alert("Cookie value is " + value) }); 

    // or use a more advanced callback function for getting our cookie
    // the cookie value is the first param
    // an object containing the different storage methods
    // and returned cookie values is the second parameter
    function getCookie(best_candidate, all_candidates)
    {
        alert("The retrieved cookie is: " + best_candidate + "\n" +
        	"You can see what each storage mechanism returned " +
    		"by looping through the all_candidates object.");

    	for (var item in all_candidates)
    		document.write("Storage mechanism " + item +
    			" returned: " + all_candidates[item] + "<br>");
    }
    ec.get("id", getCookie); 

    // we look for "candidates" based off the number of "cookies" that
    // come back matching since it's possible for mismatching cookies.
    // the best candidate is most likely the correct one
    </script> 

Sursa: http://samy.pl/

Edited September 20, 2013 by Silviu