以下内容是对网上一些资料的总结

Flex SharedObject 介绍(转自http://www.eb163.com/club/thread-3235-1-1.html):

Flash的本地共享对象是在用户机器上实现持久化存储的数据集合。Flash可以从程序中控制这些数据集合，向其中存入或者从中读取大量的信息数据。

使用SharedObject对象

　　对象说明：SharedObject（共享对象）可以看作是小型的数据库，我们可以用它来存储任何Flash支持的数据类型，比如数字、字符串、数组和对象等等。SharedObject按存放位置可分为本地型（存在客户端）和远程型（存在服务器端）。本地型共享对象的扩展名为.sol。
　　用法：下面是关于本地型共享对象的部分最主要的方法、属性的介绍。
1）getLocal(name)　方法 　“name”参数共享对象名，返回共享对象的参照
2）flush　　　　　 方法　　立即把数据写入共享对象
3）data　　　　　　属性　　存取共享对象数据的通道

只需要掌握以上这些知识就可以用共享对象来存取外部数据了。
SharedObject.getLocal(objectName [, localPath])
其中objectName是该共享对象的名字，localPath即共享对象所在路径。

// 创建一个本地保存数据的对象
var cookie:Object = SharedObject.getLocal("cookie");

方法会在默认的路径下生成一个cookie.sol文件。文件的默认大小不能超过100k，当然可以通过鼠标右击flash窗口，选择设置来管理或者禁用您的本地共享对象。可以让每个flash独立使用自己的SharedObject，当然也可以做一个全域的SharedObject让所有的swf使用，只要给localPath 赋值 "/"。
在win2k和 win xp中，默认路径为C:\Documents and Settings\username\Application Data\Macromedia\Flash Player\#SharedObjects (username为机器的用户名)

每个对象都会有一个只读属性data，用来存储被存储到“数据特性”中的对象的属性，这些属性可以共享/存储，每一个属性可以是各种基础数据类型（数组，数字布尔值等）对象。现在cookie已经存储在 SharedObject中了，以后你可以通过对SharedObject数据属性的存取来实现对cookie的存取。例如：

cookie.data.name = "张三";
cookie.data.password = "123456";
cookie.data.rememberPassword = true;

共享对象的写入会在应用程序退出时自动执行，也可以通过cookie.flush()强制写入。

　　示例：按方法一设置场景，然后输入下面的代码。

var user_so = sharedobject.getlocal("user"); // 建立共享对象的参照

send_btn.onRelease = function() {

   with (user_so) {

   data.name = name; //用data属性和flush方法保存用户输入的用户名　　　　　

   flush();

 }

};

本地型共享对象只能把数据保存在默认路径下，而且扩展名只能是.sol。这种方法的作用与设置cookies的作用类似。

       只有必须在不同flash对象之间共享数据时才需要在SharedObject.getLocal()方法中指定path参数，将所有必须共享数据的flash对象都单独放到一个目录下。

SharedObject应用后生成的文件在本地的存放目录(转自:http://bbs.airia.cn/FLEX/thread-3956-1-1.aspx):

* Windows XP:
         o For Web sites: C:\Documents and Settings\<user>\Application Data\Macromedia\Flash Player\#SharedObjects\<random code>\<domain>\<path>\<object name>.sol
         o For AIR Applications, C:\Documents and Settings\<user>\Application Data\<AIR Application Reverse Domain Name>\Local Store\#SharedObjects\<flash filename>.swf\<object name>.sol
   * Windows Vista
         o C:/Users/username/<user>/AppData/Roaming/Macromedia/Flash Player/#SharedObjects/<domain>/<path>/<flash filename>.swf/<object name>.sol
   * Mac OS X:
         o For Web sites, Macintosh HD:Users:<user>:Library:Preferences:Macromedia:Flash Player:#SharedObjects:<random code>:<domain>:<path from webserver>\<object name>.sol
         o For AIR Applications, Macintosh HD:Users:<username>:Library:Preferences:<AIR Application Reverse Domain Name>:Local Store:#SharedObjects:<flash filename>.swf\<object name>.sol
   * Linux/Unix:
         o /home/<User>/.macromedia/Flash_Player/#SharedObjects/<domain>/<path>/<flash filename>.swf/<object name>.sol

在Flex中利用SharedObject实现Cookie功能(转自:http://www.gold98.net/blog/article.asp?id=748):

SharedObject提供了下面的操作本地对象的方法：
SharedObject.clear() 删除本地共享对象；
SharedObject.flush() 立即把共享对象数据写入本地文件；
SharedObject.getLocal() 创建或连接本地共享对象；
SharedObject.getSize() 取得本地共享对象的指定大小数据。

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationComplete="init(event)" borderColor="#FFFFFF" themeColor="#FFFFFF" width="800" height="600" backgroundColor="#FFFFFF"
textAlign="center" verticalAlign="middle" horizontalAlign="center" backgroundImage="@Embed(source='lt1.jpg')">
<mx:Script>
    <![CDATA[
        import mx.controls.Alert;
        import mx.events.FlexEvent;
        private function init(event:FlexEvent):void {
        // 创建一个本地保存数据的对象s  
        var test:SharedObject = SharedObject.getLocal("testcookie");
        test.data.user = "testuser";
        test.data.psw = "testpwd";
        test.flush(); //提交保存

        var test2: SharedObject = SharedObject.getLocal("testcookie");
        Alert.show(test2.data.user);
        Alert.show(test2.data.psw);
        }
    ]]>
</mx:Script>
</mx:Application>

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/meteorlWJ/archive/2009/10/15/4675659.aspx

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

自从开发了AIR，序列化一下子变得丰富了。向本地磁盘保存（比如保存配置文件等等）可以写普通文件，用内嵌的sqlite引擎。不过在我看来，还是sharedObject比较好，至少有这么几个好处：

直接存储actionscript数据结构，不用自己写序列化和反序列化算法。其它的像sqlite，就不得不在数据结构和字符串之间转换而且还不得不类型检查。
过程是同步的。 像sqlite就不得不用事件监听来读取数据，异步方式增加workflow复杂性。
不过也有些坏处：

存储量有限。这几乎不会是问题，有哪个AIR会存储很多很多内容呢。
不够安全。除非不是一般人，否则没人知道存储在哪里。
我在公司的AIR产品上重构了配置文件部分，并开始使用sharedObject保存内容，感觉简单了很多。这里再推荐几个东西：

sharedObject查看工具：An AIR Shared Object Reader

http://blog.coursevector.com/minerva

sharedObject保存位置：

Windows XP:
For Web sites: C:\Documents and Settings\<user>\Application Data\Macromedia\Flash Player\#SharedObjects\<random code>\<domain>\<path>\<object name>.sol
For AIR Applications, C:\Documents and Settings\<user>\Application Data\<AIR Application Reverse Domain Name>\Local Store\#SharedObjects\<flash filename>.swf\<object name>.sol

Windows Vista
C:/Users/username/<user>/AppData/Roaming/Macromedia/Flash Player/#SharedObjects/<domain>/<path>/<flash filename>.swf/<object name>.sol

Mac OS X:
For Web sites, Macintosh HD:Users:<user>:Library:Preferences:Macromedia:Flash Player:#SharedObjects:<random code>:<domain>:<path from webserver>\<object name>.sol
For AIR Applications, Macintosh HD:Users:<username>:Library:Preferences:<AIR Application Reverse Domain Name>:Local Store:#SharedObjects:<flash filename>.swf\<object name>.sol

Linux/Unix:
/home/<User>/.macromedia/Flash_Player/#SharedObjects/<domain>/<path>/<flash filename>.swf/<object name>.sol
Edison.sl的签名
文章来自: 闪客居(http://www.flashas.net/) 详文参考：http://www.flashas.net/html/air/20090416/4049.html

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

深入SharedObject----本地共享对象 收藏
SharedObject是一个用来使数据持久的类，具有将数据保存到本地和远程(服务器)的功能。

首先看本地数据持久

// objectName是该共享对象的名字, localPath即共享对象所在路径

SharedObject.getLocal(objectName [, localPath])

下面创建一个共享受对象

// 创建一个本地保存数据的对象

var cookie:Object = SharedObject.getLocal("cookie");

会在默认的路径下生成一个.sol文件

我用的是XP系统，拥护名是shanghai, 这个默认的路径在我使用的机器上如下:

C:\Documents and Settings\shanghai\Application Data\Macromedia\Flash Player\localhost

在该目录下会有一些其他的目录，慢慢找就会找到cookie.sol文件, 数据就保存在这个文件里头。

哇鳃，这里我也没弄明白，这个路径是怎么回事，

那么下面开始注意 cookie.data

每一个共享对象都会有这个属性data，你希望保存的数据就是保存在这个data底下。

比如说

cookie.data.name = "sshc625";

cookie.data.sex  = "男";

cookie.data.school  = "WHUT";

那么我在这个data底下保存了我的一些信息。

通常标准做法是这样的。

if(cookie.data.name == undefined) {

    cookie.data.name = "sshc625";

}

路径问题

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/sshcx/archive/2006/06/07/777580.aspx

===========================

===============================

Flash本地共享对象（1）

Flash的本地共享对象（Local Shared Object，LSO）是在用户机器上实现持久化存储的数据集合。Flash可以从程序上控制这些数据集合，向其中存入或者从中读取大量的信息数据。例如，Flash可以在LSO中存储原生的ActionScript数据类型，包括对象、数组、数字、布尔及字符串 。这意味着，开发人员在将数据存入到LSO之前不必再靠自己实现的序列化/反序列化方法对数据进行编码。不过，LSO无法存储Flash的可视化对象，例如声音、动画或者影片剪辑。在默认情况下，一个LSO的容量是100KB。用户可以通过Flash
Player的设置管理器（如图8-12所示）为某个网站分配更多的空间，并且没有上限限制。

图8-12  设置管理器允许用户为 LSO分配更多的空间，或者将它们都禁用

LSO是在2002年3月作为Flash 6.0的一个新功能引入的，并且在本书出版的时候几乎97%的Web用户都安装了LSO 。高存储容量、即使重启机器也能存储数据的能力，以及广泛的市场覆盖面，使得LSO在长期数据存储方面成为了一个非常有竞争力的解决方案。

LSO有些时候也因为其超大的数据存储量被称为Flash cookies或者超级cookie。但是，LSO在很多方面还是与传统HTTP cookie存在着差异。首先，LSO是由Flash虚拟机来管理的，浏览器无法访问到LSO。这意味着，与cookie不同，存储在LSO中的数据不会随着HTTP请求一同发送出去。因此，与使用Set-Cookie报头修改cookie的方法不同，我们无法通过HTTP响应报头来修改存储在LSO中的数据。由于是由插件而不是浏览器来管理LSO，用户也无法像通过浏览器、像删除离线内容或者cookie一样，删除掉LSO中的数据。结果是，即使是一个对隐私安全非常注意的用户，即使他定期都清除cookie及浏览器缓存，LSO依然能在他的机器上存留很长时间。LSO同样也不能像cookie那样设置过期时间，因为在LSO中甚至都不存在过期的概念。LSO中的数据会一直存在着，直到它们被彻底删除。我们可以通过Flash
Player的设置管理器删除掉LSO中实际包含的文件，如图8-13所示。

图8-13  通过Flash Player的设置管理器可以删除掉一个或多个的LSO

这会引起一个问题：LSO如何在客户端机器上进行存储？实际上，LSO都会以.sol的文件格式存储在用户机器上一个名为#SharedObjects的特殊目录下。对于Windows XP系统来说，该目录的路径为C:\Documents and Settings\<USER-NAME>\Application Data\Macromedia\Flash Player\#SharedObjects。而在Linux操作系统中，该目录路径为~/.macromedia/Flash_Player/#SharedObjects。在#SharedObjects目录下，有一个由8位随机字母或数字生成的目录，用来存储LSO。由于8位字母和数字的随机组合排列，可以生成2.8兆可能的值，所以可以保证每个人的LSO存储目录路径都不相同
。首先，在这个随机目录下会为每个提供Flash对象（用来生成LSO）的主机创建一个同名的目录；然后，在这个由主机名命名的目录下还会包含更多代表Flash对象的目录。图8-14表明了由flash.revver.com创建的LSO如何以.sol的文件形式存储在本地机器上。

图8-14  创建的Flash LSO文件会存储在#SharedObjects中对应的Flash目录下

在这个例子中，我们原本是访问视频分享网站Revver中的http://one.revver.com/watch/ 285862，为了一睹lonelygirl15的视频。在这个页面中有一个OBJECT标签连接到http://flash.revver.com/player/1.0/player.swf这个Flash播放器，该Flash对象会将LSO数据存储到图8-14中的目录下，取名为revverplayer.sol。因此，LSO
在本地文件系统中的完整路径为C:\Documents and Settings\(USER_NAME)\Application Data\Macromedia\Flash Player\#SharedObjects\ (RANDOM_NAME)\flash.revver.com\player\1.0\player.swf\revverplayer.sol。不难看出，本地机器上的LSO路径与Web服务器上的Flash路径是一致的。注意，Flash对象的名称实际上是LSO存储路径的最后一个目录名。这就使得一个Flash对象可以在不同的文件名下保存不同的LSO。最后要注意的是，存储LSO的目录名是实际存放Flash对象的主机名，而不是引用该对象网页所在的主机名。

8.3  Flash本地共享对象（2）

这样就可以让其他的Flash对象也可以访问由play.swf存储的LSO吗？答案是：不。存储LSO的Flash对象是.sol文件路径的一部分。即使在flash.revver.com存放player.swf的同目录下有另外一个Flash对象OtherFlash.swf，也会由于错误的目录路径而造成无法访问revverplayer.sol。对于OtherFlash.swf来说，也无法访问客户端机器的\player\1.0\player.swf目录。

在数据共享访问方面，LSO默认的安全规则要比cookie严格得多。同cookie一样，默认的LSO也禁止其他域访问其中的数据。更严格的部分在于，LSO只能由创建它的对象来访问，这相当于在cookie中设置Path属性。但是，对于创建LSO的Flash对象来说，其文件名不过是Path属性的一部分。

我们已经说过，在LSO的存储路径中包含Flash对象的名字可以防止其他对象访问它。如果想让两个Flash对象共享一个LSO中的数据，我们必须在创建该LSO时指定其存储路径，去掉其中的Flash对象名。在ActionScript中，我们可以在调用SharedObject.getLocal()方法时，将指定路径作为方法的第二个参数传递进去。例如，假设某网站有两个Flash对象foo.swf和bar.swf，各自的访问路径分别为http://site.com/media/some/dir/foo.swf和http://site.com/media/other/dir/bar.swf。这时，对于foo.swf来说，有4个路径可以用来读写LSO：/media/som/dir/、/media/some/，/media/或者/，此外，还有一个只能由foo.swf读写的路径/media/some/dir/foo.swf/。同样，bar.swf也有4个可用于读些LSO的路径：/media/other/dir/、/media/other/、/media/或者/，以及一个只能由bar.swf读写的路径/media/other/dir/bar.swf/。因此，foo.swf或者bar.swf在/media/或者/中写入的任何LSO，另一个Flash对象都可以进行读取，反之亦然。

我们继续它与cookie之间的比较。LSO也有一个安全标志，类似于cookie中的Secure属性。在创建LSO的ShareObject.getLocal()方法中，该标志是以一个布尔值的形式，作为第三个参数传递给方法的。当该参数设置为true时，只有建立了安全连接的Flash对象才可以访问LSO。同路径参数相比，安全标志参数限制了哪个Flash对象可以访问哪个LSO。不过，由于LSO中的数据并不会像cookie一样随HTTP请求一同发送出去，因此安全参数也不像cookie中保护数据泄露那样重要。

最后，二者之间尚未比较的便是cookie中的Domain属性。Flash提供了一种称为"跨域脚本"的功能，它不只是在多个域之间共享客户端数据那么简单。通过跨域脚本，一个域中的Flash对象可以加载另一个域中的Flash对象，并且可以访问其内部的方法和变量！这是一个可选的单向过程。如果http://site.com/上的Flash1.swf想要访问http://other.com/上Flash2.swf中的数据，那么Flash2.swf必须明确允许Flash1.swf这样做。即使Flash2.swf允许Flash1.swf访问，如果没有Flash1.swf的允许，Flash2.swf也无法访问Flash1.swf中的内容。

Flash2.swf可以有两种允许跨域的方式。第一种方法是在Flash对象的代码中使用System.security.allowDomain()方法进行授权，这样每个Flash对象都可以控制跨域的权限。在我们的例子中，http://other.com/上Flash2.swf中的代码就应该包含如下的语句：System.security.allowDomain('site.com')。开发人员可以通过重复调用该方法，为不同的域添加权限，也可以使用通配符*为整个子域授权。例如，System.security.allowDomain('*.site.com')可以为site.com下的所有子域，例如press.site.com或者qa.site.com都授予跨域权限。在Flash中并不需要遵循cookie中的两点规则，因此开发人员可以使用System.security.
allowDomain('*')，允许整个互联网访问该Flash对象！这个安全措施的目的非常明确，我们可以将访问Flash对象中变量和方法的权限授予任何网站中的任何人。

第二个授予跨站脚本权限的办法是使用一个全局的规则文件。该文件同样也会调用System.security.allowDomain()方法，只不过它针对的是当前域中的所有Flash对象。通常，该规则文件都会以crossdomain.xml的文件名存储在网站的Web根目录下。以下是Amazon.com中使用的跨域规则（位于http://www.amazon.com/ /crossdomain.xml）：

<cross-domain-policy>
<allow-access-from domain="*.amazon.com"/>
<allow-access-from domain="amazon.com"/>
<allow-access-from domain="www.amazon.com"/>
<allow-access-from domain="pre-prod.amazon.com"/>
<allow-access-from domain="devo.amazon.com"/>
<allow-access-from domain="images.amazon.com"/>
<allow-access-from domain="anon.amazon.speedera.net"/>
<allow-access-from domain="*.amazon.ca"/>
<allow-access-from domain="*.amazon.de"/>
<allow-access-from domain="*.amazon.fr"/>
<allow-access-from domain="*.amazon.jp"/>
<allow-access-from domain="*.amazon.co.jp"/>
<allow-access-from domain="*.amazon.uk"/>
<allow-access-from domain="*.amazon.co.uk"/>
</cross-domain-policy>

从上面的规则中我们可以看到，6个不同国家所有子域间的Flash对象都可以互相访问。不过奇怪的是，在这个规则列表中存在部分冗余：*.amazon.com已经包括了http://www.amazon.com/和images.amazon.com。

在全局规则中使用<allow-access-from domain="*">（或者与其类似的*.com、*.net或者*.org）是非常危险的。Flash虚拟机（VM）除了会检查crossdomain.xml文件中的授权，还会检查在Flash对象中硬编码的授权。换句话说，最后决定的授权是二者的并集，而不是交集。假设有一个名为MembersAPI.swf的Flash对象，为了确保只有member.site.com中的Flash对象才能进行跨域访问，在代码中使用了System.security.allowDomain
('member.site.com')。如果此时IT管理员或者其他的开发人员在部署的crossdomain.xml文件中添加了一条"*"，那么互联网中所有的网站都可以访问这个MemberAPI.swf了。更糟的是，因为应用程序还像以前一样正常工作，所以开发人员对网站正处于危险中的情况还毫不知情！

这并不是我们凭空假想出来的情形。在2006年8月，著名的Web安全专家Chris Shiflett发现并提出了这一漏洞 。他注意到，像Flickr这些知名照片分享网站的跨域规则中都设置了<allow-access-from domain="*">，使得互联网中所有的远程脚本都可以调用Flickr中的Flash对象。在Julien Couvreur的帮助下，他在自己的域中创建了一个网页，其中的Flash对象可以通过跨域脚本来加载Flickr中的任意Flash对象，从而实现对Flickr用户好友列表的管理。当Flickr的某个用户访问Chris的页面时，其中的Flash对象可以控制Flickr中的Flash对象，将Chris添加到该用户的好友列表中。这很像我们在第13章"JavaScript蠕虫"即将讨论的Samy蠕虫。正是因为Flickr将Flash对象共享出去，所以Chris才有机会操纵其进行一些恶意行为。

8.3  Flash本地共享对象（3）

如果读者正在开发的应用程序必须使用"*"来允许整个网络的跨域授权，那么应该重新考虑这个应用程序的架构了。除了某些在Web Mashup程序中使用的开放API之外（请参考第11章"Web聚合"），开发人员应该知道哪些域可以访问程序中的Flash对象。如果真遇到API的情况，我们也应该将这些全局共享的Flash对象隔离到一个单独的域中，例如api.host.com，从而保护其他域和子域中的Flash对象。这也正是Flickr用来解决Chris Shiflett所发现安全问题的办法。图8-15显示了一个虚构的在线书店BillysBooks.com如何既为风险资本的Mashup程序提供开发API，同时又保护处理关键功能的Flash对象。

图8-15  将全局访问的Flash对象隔离到一个单 独的子域中，可以保护其他的敏感数据

虽然LSO是经过序列化之后才存放在.sol格式的文件中，但是该文件格式非常容易被反向工程分析，并且非常容易读懂，现在已经有了很多开源的工具可以用来阅读并修改LSO中的内容。开发人员不能够相信从客户端存储中获得的任何数据，必须在使用前先经过验证。在图8-16中，我们使用了Alexis Isaac提供的开源工具--Sol Editor来修改一个LSO。该LSO用来跟踪并记录用户加入测试会员的时间，通过修改该LSO中的日期，我们已经成为了合法的测试会员。这是本书作者在进行安全评估时，从一个成人网站上发现的真实案例。

图8-16  攻击者有一大堆的免费工具， 可以用来查看或者修改Flash LSO

下面是关于Flash本地共享对象的总结。

LSO是持久化的。开发人员可以使用浏览器的unload()事件来清除LSO数据，从而模拟非持久化存储。

LSO不能设置自动过期，必须由开发人员来实现该功能。

在默认情况下，LSO只能被创建该LSO的Flash对象访问。程序员必须在创建LSO时明确指定同域中的其他Flash对象访问。

只有必须在不同Flash对象之间共享数据时才需要在SharedObject.getLocal()方法中指定Path参数，将所有必须共享数据的Flash对象都单独放到一个目录下。

Flash的跨域脚本可能会非常危险，开发人员必须小心哪些域是允许访问的。

LSO可以存储像数组、对象及布尔等复杂的数据结构。Flash Player会负责数据的序列化和反序列化。

通过某些工具可以轻易查看或修改LSO中的内容，而且像这样的工具有很多，例如Alexis Isaac的开源工具Sol Editor。Flash内部并没有集成防止对LSO篡改的检验。