Location of Shared Objects and Settings

The SharedObject class allows Flash movies to create persistent, cookie-like data on a user's machine. You perform this operation by calling SharedObject.getLocal. This operation stores persistent shared objects to—and later retrieves them from —a location that depends on the domain of the movie that calls getLocal, as well as (optionally) part or all of the movie's URL.

Movies connecting to Flash Communication Server MX can also create locally persistent shared objects by calling SharedObject.getRemote. The changes described here for getLocal also apply to locally persistent shared objects created with getRemote.

Every domain has a shared object quota. This is an allocation of the user's disk space in which movies from that domain may store persistent shared objects. Users can change the quota for a domain at any time by choosing Settings from the Flash Player context menu. When a movie tries to store a persistent shared object that causes Flash Player to exceed its domain's quota, a dialog box appears, asking the user whether to increase the domain quota.

Flash movies connecting to Flash Communication Server can send audio and video streams from users' microphones and cameras by calling Microphone.get and Camera.get. When a movie does so, Flash Player displays a privacy dialog box that asks the user whether a movie can use their microphone or camera. When users reply, they can make their answer permanent. When that happens, Flash Player records their decisions on a per-domain basis. For example, if a movie from www.mysite.com asks to use the user's camera or microphone and the user specifies a permanent Yes for that domain, then any movie from www.mysite.com can call Microphone.get or Camera.get afterwards with any movie requests without displaying the privacy dialog box.

SharedObject, Microphone, and Camera functionality has existed since Flash Player 6.

Applying the rules

In Flash Player 6, the domains that Flash Player chooses for shared object storage, shared object quotas, and privacy settings are superdomains. For example, for a movie from www.mysite.com, Flash Player 6 would use the superdomain mysite.com.

Flash Player 7 chooses domains based on the version of the movie that's playing. For movies made for Flash Player 6, Flash Player 7 continues to use superdomains by default. For movies made for Flash Player 7 or later, Flash Player 7 uses the exact domain of the movie by default. For example, for a Flash Player 7 movie from www.mysite.com, Flash Player 7 would use the exact domain www.mysite.com.

Choosing which rules to use

You can override the defaults (superdomains for Flash Player 6 movies and exact domains for movies made for Flash Player 7 or later) by setting a new global variable called System.exactSettings. When you set this variable to true, Flash Player 7 uses exact domains; when you set it to false, Flash Player 7 uses superdomains.

Normally, these defaults should be reasonable but there are two major scenarios where you might want to change the value of System.exactSettings from its default value:

• If you have a movie made for Flash Player 6 that has created persistent shared objects and you want to upgrade it to a Flash Player 7 movie and you want to be able to retrieve the shared object data created by the version 6 movie, then you should set System.exactSettings = false in the Flash Player 7 movie. This forces Flash Player to read persistent shared objects from the movie's superdomain. This is desirable because it stored them there when the Flash Player 6 movie created them.
• If you have multiple cooperating movies, some made for Flash Player 6 and some for Flash Player 7 (or later). If these movies need to share the data in a persistent shared object, you must ensure that they all have the same value for System.exactSettings so that Flash Player uses the same domain for all of them.

If you change the value of System.exactSettings from its default, do so very early in your movie, preferably at the beginning of Frame 1. Flash Player will not allow you to change the value of System.exactSettings after it has used it once in a decision about shared objects or privacy settings.

It is never possible to read or write persistent shared objects from another domain. If you need to access data in another domain's persistent shared objects, create another movie that you serve from that domain and transfer the data using ActionScript, which will probably involve calling System.security.allowDomain (described earlier in the section Granting Cross-Movie Scripting Permissions).

Debugging Security Problems

As we mentioned earlier in the section Security Restrictions for Data Loading, you can diagnose data-loading problems caused by differences between Flash Player 6 and Flash Player 7 using the mm.cfg and flashlog.txt files. However, you can debug security in your movies more comprehensively by publishing your movies with debugging enabled. Play your movies from their production URLs using the Debug version of a browser player (ActiveX control or plug-in) and connect to the Flash authoring application when playback begins. When movies play while connected to the Flash Debugger, warning messages appear in the Output panel if a security check fails. These warning messages report the URLs involved in the security check, which help you determine security-related problems so you can fix them.

Flash Player 7 continues to improve on the Flash Player tradition of stability, performance, and security. With the changes described in this article—exact domain matching and HTTPS protection—Flash Player 7 fulfills the Internet community's expectations for client-side security better than before.

The introduction of policy files also makes Flash Player's security model more flexible to the needs of Flash developers. Previously, it was impossible to load non-SWF data from other domains. Now Flash developers can do so easily. This new permission mechanism opens the way to a whole new class of Rich Internet Application, including applications that can access web services directly from the client.

To remain up to date about Flash security, please read the latest security documents in the Flash Player Develper Center.

Page 6 of 6

Previous Page