Beginning ActionScript 2.0 2006

Chapter 22

1.Open the crossdomain.xml file and add the following XML to it:

<?xml version=”1.0”?>

<!DOCTYPE cross-domain-policy SYSTEM “http://www.macromedia.com/xml/dtds/cross- domain-policy.dtd”>

<cross-domain-policy>

<allow-access-from domain=”*.someserver.com” secure=”false”/> </cross-domain-policy>

2.Save the file.

3.Upload the file to the root of the base domain on the HTTPS server. The unsecure SWF is allowed access to the HTTPS domain.

How It Works

By using the secure attribute, you can specify that an HTTPS domain can allow SWF files residing on a non-secure domain to access data on the secure domain.

This is, of course, not suggested. The only time you might want to do this is if the HTTPS and HTTP servers both resided behind the same firewall, such as on a corporate intranet. Another instance might be for testing purposes.

By using a secure attribute with a value of false, you are side-stepping the very purpose of HTTPS. An alternative solution should be found.

Load a Policy File from a Subfolder

If you do not want to host the policy file at the root folder of port 80 on the remote server, you can place the policy in a subfolder of your choice. The SWF file loading the policy file needs to know where to get it. To do that, load the policy file manually using the method that resides in the security object within the system class. The method is accessed with the following syntax:

System.security.loadPolicyFile(URL:String);

This line must be placed in your ActionScript before your SWF attempts to load any data from the remote domain. The URL parameter must be a string and refer to the location where you have placed the policy file. For example, you can place the policy XML file in a subfolder on your domain called policies. When using this method, you do not need to name the file crossdomain.xml. You can name the policy file whatever you want. Because you can now make unique policy filenames, you can set up specific policies for specific SWF files accessing the same server. The line of code for accessing a specific policy file would look like the following:

System.security.loadPolicyFile(“http://www.someserver.com/policies/policyforBetaSWF

.xml);

Be aware that this allows your SWF to access only the data that resides within the subfolder or any child folders within that specific subfolder.

568

Reading XML

The loadPolicyFile method overrides the native policy check at the root of the domain. If a specific policy file in a subfolder fails to load, Flash automatically attempts to load the default crossdomain.xml file.

In this way you can disable or modify a security policy at runtime. You can disable the policy within your SWF by calling a null policy file. You place this line in your code wherever you would like to disable script access:

System.security.loadPolicyFile(“http://www.someserver.com/policies/Rempovepolicyfor

BetaSWF.xml);

This should load a null XML file that looks like the following:

<?xml version=”1.0”?>

<!DOCTYPE cross-domain-policy SYSTEM “http://www.macromedia.com/xml/dtds/cross- domain-policy.dtd”>

<cross-domain-policy> <allow-access-from domain=””/>

</cross-domain-policy>

Using a Policy File with an XML Socket, without HTTP

When using a policy file with an XML socket, you should understand how to create a basic Socket transaction. Socket transactions should be approached with caution when scoping for application creation deadlines. Due to the asynchronous communication, multiple client setups, and potential database activity, sockets can be challenging and time consuming. XML Sockets are among the most difficult processes to script in any language.

Consider the situation in which a policy file is used to allow XML socket access. You can load a policy file as you would any data load using the default methods provided by Flash and covered in the preceding Try It Out examples. Still, there are times when offering HTTP is not feasible, and the policy file must be sent via the XML socket itself. The socket server will contain a special provision for handling a policy file request, properly formatting the XML with a null end byte.

A socket server policy file contains an extra attribute that you can use to restrict the access by port, or port spans. You can also use wildcards within the port specification. An example policy response from the socket that restricts ports could look like this:

<cross-domain-policy>

<allow-access-from domain=”www.someserver.com” to-ports=”2222” /> <allow-access-from domain=”someserver.com” to-ports=”555,2222” />

<allow-access-from domain=”192.168.1.1” to-ports=”555 - 2222” > <allow-access-from domain=”www.anotherserver.com” to-ports=”*” />

</cross-domain-policy>

To access the policy file, the socket server must be listening on a specific port in which the initial transaction is the policy file when Flash’s initial handshake is the string:

<cross-domain-request/>

569

Chapter 22

A socket policy request would look like this:

System.security.loadPolicyFile(“xmlsocket://www.aremoteServer.com:2222”);

You can see you can specify different types of ports. You can request the policy file on its own port or configure your socket server to send the request over the same port. If you specify a port that serves only the policy file, and this port is not included within the actual domain and ports specified within the cross-domain policy file, you will no longer be able to access the port that served the policy file. Because of this, you want to remember to add the policy port or serve the policy file from the same port or ports that the policy file specifies for the entire socket application.

Using Shims and Proxies

Shims and proxies are doorways. Both are methods of bouncing a data request through a secondary object that does not have the same security restrictions as the main application. Sometimes you may not have access to placing policy files on a server to enable your application to load data from those servers. In these cases shims and proxies can help.

Proxies: Forcing Data Access

Proxies may be the easiest method for loading cross-domain data. Proxies are scripts that do not run in Flash but run in a script environment on the same server that is hosting the Flash application. Script environments such as Perl, Python, PHP, ASP, and more are capable of providing proxy scripts. A server environment is not subject to the same security issues as Flash. When you instruct a script running on your server to fetch data, it simply does so. With proxy scripts you can alter the data and format it for a Flash application.

The following exercise uses PHP, which is offered by almost every hosting service. PHP is often already set up and ready to go on web site hosting companies’ servers. If you know ASP, Perl, or some other language that you prefer, you can substitute the proxy with your own.

1.Open your favorite text editor, create a new text document, and enter the following code:

<?php readfile($remoteURL);

?>

2.Save the file as proxy.php.

3.Upload the file to your server. Your server must have PHP enabled and working for this example to work.

4.To test the proxy, append the remoteURL variable to the URL of the proxy and see whether you can see the data. For example, try this URL, but replace the domain with your own:

http://www.someserver.com/proxy.php?dataURL=http://www.weather.gov/alerts/il.rss

5.After you know your proxy is working, you can place an SWF on the server, which will access the proxy.

6.Open a new Flash document and save it in your work folder as myMovie.fla.

570

Reading XML

7.Click the first frame in the timeline, open the Actions panel, and type the following ActionScript code:

var My_Data:XML = new XML(); My_Data.ignoreWhite = true; My_Data.onLoad = function(success){

if(success){

trace(this);

}else{

trace(“My_Data failed”);

}

}

dataRequest:LoadVars = new LoadVars();

dataRequest.dataURL = “http://www.weather.gov/alerts/il.rss”; dataRequest.sendAndLoad(“http://www.someserver.com/proxy.php”,My_Data,”Get”);

8.Test the code by pressing Ctrl+Enter. After a moment, the output window will show you the raw string that was loaded via the proxy.

How It Works

Because the proxy PHP file and the SWF reside on the same domain, Flash has no issues loading the data received when requesting the file specified in the dataRequest object.

There are a couple of things to keep in mind. One is the content-length header information. Without a content-length header, Flash has no way of populating getBytesTotal with a value. To send this you would need to acquire the file size via PHP manually and add it to the return object in the PHP script.

The other issue to keep in mind is that although the remote file doesn’t exist within your own domain, it is being served as if it is. That means for every byte you proxy through your web site, you effectively pay for it depending on whether or not you rent your server, and how your server accesses the Internet. If you proxy large files this might get expensive. You are going to find your server stats reflect bytes sent via a proxy as literally bytes sent through your own domain. So think about how much the file will be accessed, and understand the limitations of your server and service provider contracts.

This is also a good time to mention that although you can pass through data from virtually any public space with a proxy, that doesn’t make it legal. You should verify that data is free to use. Obtain permission when using someone else’s data, or use your own.

Some providers have begun to add extra security and require extra hoops to access remote data via scripts. In these cases, such as dreamhost.com, the help documents and developer forums often provided by the service provider contain work-arounds and scripts you can use in step 1 of this example.

Shims: Allowing Script Access

A shim is something that comes between two things. A wood shim can keep a door or window open. Think of a Flash shim in much the same way. A shim comes between you and a closed door. It provides a doorway for accessing data on a remote domain. The caveat is that you need to be able to access the remote domain so that you can upload the shim to the remote server. Without this one requirement, you will need to find a different solution.

571

Chapter 22

An SWF on the Web has the capability, without security concerns, to load an SWF from anywhere else on the Web, no matter where it resides. There is, however, one large limitation: the ActionScript object in the main SWF cannot access the ActionScript objects in the guest SWF. Also the guest SWf cannot access the ActionScript objects of the main SWF. So although you can load the SWF, it will be unable to communicate or enact code in the main SWF. To enable script access, Flash uses an Allow domain object.

The Allow domain object is very similar to the policy file. All of the same domain, subdomain, alternative URLs, and secure server considerations apply. If you haven’t yet read the policy file section earlier in the chapter, you should do so now. The policy file is the preferred method, especially if you have access to uploading the file to the remote domain.

Because a shim is an option, you learn about it here. Also, there are times when you’d like to run an SWF application within your own application. Although the example is a pure shim, you can imagine a guest SWF acting as a full application API filled with Web services objects to be made accessible to the main application.

1.Open a new Flash document and save it in your work folder as shim.fla.

2.Click the first frame in the timeline, open the Actions panel, and enter the following ActionScript code. Replace the domain string with the actual domain on which you’ll be hosting your main SWF:

System.security.allowDomain(“www.somedomain.com”);

LoadVars = LoadVars;

3.Publish the SWF.

4.Open your favorite text editor and write a simple one-line statement, such as “This is my remote data.” Save the text file as remoteDat.txt.

5.Upload remoteDat.txt and shim.swf to the remote server.

6.Open a new Flash Document and save it in your work folder as main.fla.

7.Click the first frame in the timeline, open the Actions panel, and type the following ActionScript code:

this.createEmptyMovieClip(“shim”, 0); this.createTextField(“out”, 1, 10, 10, 200, 40); watchLoad = function () {

if (shim.LoadVars != undefined) { myData:LoadVars = new shim.LoadVars(); myData.onData = function(str) {

out.text = str;

};

myData.load(“http://www.remoteDomain.org/remoteData.txt”);

clearInterval(loader);

}

};

var loader:Number = setInterval(this, “watchLoad”, 1); shim.loadMovie(“shim.swf”);

//shim.loadMovie(“http://www remoteDomain.org/shim.swf “);

572

Reading XML

8.Publish this FLA and upload it to the server that your users will be accessing directly.

9.When you navigate to main.swf you will see the text field populate with the data from the remoteData.txt file residing on the remote domain.

How It Works

Shims use the System.security.allowDomain method to declare which domains may access the objects defined within it. You can specify more than one domain by inserting multiple domain strings separated by commas. Wildcards can also be used, in an identical manner as the XML policy file. For example, this is a valid allowDomain method call:

System.security.allowDomain(“beta.anotherDomain.com”, “*.somedomain.com”,

“*.yetAnotherDomain.org”);

The main.swf file can only access objects that have been explicitly defined in the shim.swf file, so you must define at least one object for main.swf to utilize. Because you can use the parseXML method to transform a LoadVars object into an XML document, and you can use LoadVars as is, you only included the single object declaration LoadVars = LoadVars; to make the shim.swf LoadVars object available to main.swf.

This is a way to make a very efficient shim. At just under 260 bytes, it has negligible load time. Of course, you could declare many more objects for use within the shim. You could create an entire class set of Web services offered by the shim. You can make the objects available in the shim as fancy as you want.

If the remote server hosting the shim is an HTTPS server, and the domain on which the main.swf file is hosted on is HTTP, you would need to use separate syntax. This works in the same way but uses the following syntax:

System.security.allowInsecureDomain(“someInsecureDomain.com”);

Summar y

This chapter described ways in which you can load XML data into Flash. You were introduced to the XML, XMLSocket, System, and security objects as well as the XML components, policy files, shims, and proxies.

You created some useful examples that showed how to use each object and considered the many issues involved with each. You loaded XML and extracted specific information from it, and you saw how Flash gives you unlimited ways to use XML files in your applications.

You spent much time with the security issues with Flash and how to work with them, keeping your applications, servers, and data safe.

Hopefully this chapter got you thinking of using Flash in ways you might not have thought of previously. The chapter covered objects that are a major asset in the tool belt of any Flash developer. Being able to work with and use XML and data with Flash can set your resume apart from the rest.

573

Chapter 22

Exercises

1.Consider the following list of domains that are hosting an SWF file. To the right of each is the domain that hosts the data. Without a policy file, which domain combinations would simply produce an alert and which would fail silently?

2.With the following XML data, load the data and a URL attribute to each station node:

<?xml version=”1.0” encoding=”ISO-8859-1”?> <channels>

<Station identification=”104.1”> <Name>

Rock And Roll Oldies! </Name>

<Desc>

Music great with hot chocolate! </Desc>

</Station>

<Station identification=”98.6”> <Name>

Rock and Roll </Name>

<Desc>

Music for waiting for Godot! </Desc>

</Station>

<Station identification=”102.5”> <Name>

Electronic Madness! </Name>

<Desc>

Arigato Rules! </Desc> </Station>

<Station identification=”107.9”> <Name>

Electronic Madness 2! <Name>

<Desc>

Thunder Dome! </Desc> </Station>

</channels>

574

Reading XML

3.With the XML you just created, use the childNodes property to access the URLs you just created. Use nodeValue and attributes properties to access the data within it, and populate an object with those values.

4.Create a pipe (|) delimited file, rather than an ampersand-delimited file. Load the data file as a raw string using the LoadVars object. Parse the name/value pairs and place them within an object.

575