基于Facebook和Flash平台的应用架构解析（二）

核心提示： 你的服务器返回SWF文件， 当用户和你的应用交互时，基于Facebook和Flash平台的应用架构解析（二）(2)，SWF可向Facebook服务器、或你的服务器发送异步请求，SWF文件中的ActionScript脚本直接访问Facebook服务器（步骤7-8），从而获得应用的密钥，接下来再传给

你的服务器返回SWF文件。

当用户和你的应用交互时，SWF可向Facebook服务器、或你的服务器发送异步请求。

SWF文件中的ActionScript脚本直接访问Facebook服务器（步骤7-8）。你可以使用Google代码中的ActionScript 3.0 Library for Facebook Platform。

出于Flash Player安全性的考虑，SWF文件只能从两类服务器获取数据：（1）提供SWF文件的服务器（这里即你的服务器）；（2）有跨域策略文件（在文件中列 出了SWF来源服务器）的服务器。也就是说，若要你的SWF能直接访问Facebook服务器，Facebook服务器必须在跨域策略文件中开放了访问权 限。如果看过Facebook的跨域策略文件，你会发现它通过一个通配符，授予了来自任何服务器的SWF文件的访问权：

<cross-domain-policy>　
　　　<site-control　permitted-cross-domain-policies="master-only"/>　
　　　<allow-access-from　domain="*"/>　
　</cross-domain-policy>

你的ActionScript访问Facebook服务器时，必须像前面非Flash的iFrame和FBML应用部分讲到的那样，传送应用API Key和用于说明访问来自何处的签名信息。利用ActionScript 3.0 Library for Facebook Platform中的类可自动生成签名；为此，你只需向ActionScript session类的构造函数传入应用的API Key和密钥。

但是，你不应在SWF文件以硬编码方式写入上述数据，因为SWF文件可用多种软件反编译。相反，SWF应该在运行时向你的服务器发出请求（可 HTTP或Flash Remoting方式），从而获得应用的密钥，接下来再传给ActionScript session类的构造函数，从而生成访问Facebook服务器时所需的签名。