Flash Download Security

Macromedia has established a security restriction that limits loading data into Flash. Whether you are using the primitive HTTP data transfer or the sophisticated XML functions, you will not be able to communicate with any web server except the one on which your Flash files are located. More precisely, you can only download from (or upload to) the sub-domain in which your swf file is located.

Similar restrictions apply, for instance, to Java programmers. They are confined to a sandbox, a set of restrictions designed to prevent malicious or careless treatment of the visiting computer. But Java developers can simply request permission from the user to ignore this limitation. This request is in the form of a pop-up window that certifies the identity of the developer and specifies the permissions that are requested . Although disturbing and crude, it is a solution to escaping restrictions. Unfortunately, Flash developers have no similar escape route.

There is an interesting exception to this rule. Every time a Flash file is played on the web, the browser can make direct contact with Macromedia.com. While there is important rationale for this design (updating software, for example), it nonetheless remains a security leak. Cautious developers are disturbed by this mandatory sharing of Internet traffic. They spin scenarios in which, for instance, the logs are analyzed to unearth business relationships that are not public but are revealed by patterns of IP traffic.

These scenarios seem farfetched ”but so do the violations that Macromedia is trying to keep us from committing. Interoperability and data sharing are growth directions for the web in general and for Flash in particular. Isn't XML a giant step in this direction? While this restriction impedes, for example, the young developer who might want to make a sexy browser for public XML sports scores, it does little to hamper the pernicious hacker, who can easily dig tunnels beneath Macromedia's barbed-wire fence. The easiest tunnel to dig would be to assemble a simple server application that lives in the accessible domain and processes the Flash requests. Such apps repeat requests and responses, speaking directly to Flash on one end and to the illicit foreign domains on the other. In upcoming chapters, we acquire the skills required and build such an application.

One type of Flash project has no such restriction. A Flash projector is a stand-alone application that combines swf content with a browserless Flash player. Flash projectors typically load from disk or CD-ROM rather than the Internet, so they have no home domain to which they are restricted. For this or some other reason, stand-alone Flash has no restrictions on the domains with which it is willing to communicate.

Similarly, a swf file located on the local file system can access any web site to download data, even though they are running in the browser. Even Flash files that are embedded in (or attached to) e-mail can connect to data on any web site. Unfortunately, they work with only certain HTML-compliant and Flash-enabled e-mail systems, depending on the e-mail client, the operating system, and even the ISP. (Forget AOL users!)

We play within the rules. All our examples comply with the restriction that the swf files and the data files (and middleware applications) reside at the same location. At first we work with simple files. We experiment with Flash and save locally, on our own computer or on a LAN. We load data from the same directory or one that can be accessed relatively easily, since this seems to be the most reliable.

We will soon use middleware as the source of our XML data. Middleware needs to run on a real server. During the experimentation process, we can create local files and access the data servers on the web. This will include URLs serving test data for readers of this book.

To make our Flash public, we will need to publish our swf files to the same domain that is hosting the middleware.

Turning the High Score Display into a Permissions Probe

It is easy to fashion our little HTTP loader into a lightweight tool for probing the domain perimeter. First we modify the initial frame. It needs to be labeled, because we will return here. So we label it Start or something even more clever. Then the URL string, which was hardcoded, has to be made into a variable. Checking the variable tries tells us if this is the first time the code is searching for a file. If so, we give it a name to start with. If not, we just reset the counter:

ActionScript

 if(tries <=0 ) {    url="highscore.txt";  } else          {    tries=0;              } loadVariables (url, this); 

Frame 4 needs a new feature or two (Figure 7.5).

Figure 7.5. Text Entry Field

A simple text field is streched across this frame. It is set to use Input Text, as opposed to Dynamic or Static Text. It is linked to the variable url and uses a common font (Figure 7.6). Finally we include a button (we reuse the AnswerButton from our earlier code, but distort it grossly). The button is scripted very simply

Figure 7.6. Input Text Field

ActionScript

 on (release) {     gotoAndPlay ("Start"); } 

Now we have a simple swf file that can be loaded in various settings ”local disk, web server, and so on ”and we can experiment with the Flash rules of data access permissions and their actual implementation.

To actually test access, we simply type in a URL and press the button. If it fails, the URL is outside the domain perimeter.

Adding the High Score Feature to the Game

The highscore MovieClip is made to be independent. It has no data connection with the rest of the fla file. We can literally just drag it into the game and it's good to go!

Open the highscore file. Make sure its library is open. Open the latest Quiz version. Just drag the highscore feature into the quiz game.

Matching Score Display

To make the game more interesting, let's create a personal score display that matches the global high score display.

Duplicate the highscore symbol in the library. Name the copy myscore and double click to open it in the editor.

Simplify myscore by deleting the code layer and all the frames except one. Finally, change the title text from "WORLDWIDE HIGH SCORE" to "SCORE" or something similar.

Return to the base movie. Make a layer called score. Drag the new myscore symbol from the library onto the stage, thus creating an instance of that MovieClip.

Now align the two score panels in the base movie. Since the first frame of highscore is invisible, it is difficult to lay out, even with the alignment features of Flash.

An easy trick is to carefully place two copies of myscore. When you are done, name each with the Instance panel. Name one myscore and one highscore (Figure 7.7).

Figure 7.7. Manipulating the Instance

For the actual highscore, while the Instance panel is open, click the Swap Symbol and change highscore to be an instance of the highscore symbol, not the myscore symbol (Figure 7.8).

Figure 7.8. Changing an Instance's Symbol

Now update the Round symbol. The score display has been a simple text object in the score display layer of the Round. It displayed the points variable. Now the score is displayed by the myscore MovieClip and recorded in the score variable in the MovieClip. Delete the score display layer altogether and change the score updates in the Win and Lose states from

ActionScript

 points=++_parent.points; 

and

ActionScript

 points=--_parent.points; 

to

ActionScript

 ++_parent.myscore.score; 

and

ActionScript

 --_parent.myscore.score; 

Now our quiz is quite handsome (see Figure 7.9). It displays both the player's local score and the public high score, which it loads from the Internet.

Figure 7.9. The Quiz with High Score and My Score