Search code examples
actionscript-3apache-flexflash-builderflash

Crossdomain policy behaviour on 302 redirects in AS3

I have crawled the web quite a lot these days, but couldn't get any accurate information on how crossdomain.xml files behave in case of 302 redirects; especially with the sandboxes having changed significantly over the last versions!

I am relatively new to flash... so any advice is more than appreciated!

I have been working on a project lately that uses audio streams with some sort of CDN distribution! what happens is that a common url is triggered, and then the user is dynamically redirected to the next best server available. In my case, i have no access at the server side of things (at least not anytime soon). And the only path providing an appropriate crossdomain.xml is the one performing the redirect. All the other dynamic paths provide exclusively content!

http://resource.domain.com (valid crossdomain.xml)

    302 => http://dyn1.domain.com/...

    302 => http://dyn2.domain.com/...

    302 => http://dyn3.domain.com/...

I noticed that flash doesn't care much if i try to load the audio stream with something like...

var req :URLRequest = new URLRequest("http://resource.domain.com");

var sound :Sound = new Sound(req); // ie. effectively playing http://dyn3.domain.com

sound.play();

It gets both redirecting, and streaming done well! and doesn't bother for any crossdomain file and starts playing!

Although when i try something different, like setting up some custom headers to the request and loading the file with URLStream instead, everything gets messy! Well, the redirect gets done, as expected but all of a sudden i need another crossdomain file in the redirected location!

Is there any explanation to whats happening and eventually ways to resolve this?!

Thanks for your time!

It comes as a site question : i noticed everything to work flawlessly while being in the local-trusted sandbox and errors happening mainly if not exclusively in the remote sandbox. is it possible that the local-trusted sandbox doesn't care about crossdomain policy files at all!?

Solution

  • Summary

    Add crossdomain.xml to each CDN host or adopt to limited Sound functionality.

    Details

    1. SWF files that are assigned to the local-trusted sandbox can interact with any other SWF files and can load data from anywhere (remote or local).

    2. Sound can load stuff from other domains that don't allow access using cross-domain policy with certain restrictions:

      Certain operations dealing with sound are restricted. The data in a loaded sound cannot be accessed by a file in a different domain unless you implement a cross-domain policy file. Sound-related APIs that fall under this restriction are Sound.id3, SoundMixer.computeSpectrum(), SoundMixer.bufferTime, and the SoundTransform class.

    3. Flash in general has pretty complex cross-domain policies but in your case the bottom line is that you'll need to have proper crossdmain.xml on each host except the one that serves the SWF:

      3.1. If your file is served from http://resource.domain.com it's not required to have http://resource.domain.com/crossdomain.xml but it's really good to have one.

      3.2. You will need to have proper http://dyn2.domain.com/crossdomain.xml explicitly allowing your SWF to access dyn2.domain.com to be able to use URLLoader and other APIs that provide access to raw loaded data.

      3.3. There's a reason for these restrictions - cookies (and other ambient user credentials). If Flash would not require proper cross-domains after a redirect, one could access any domain with user cookies attached by simply loading his own redirector first. This means accessing all user cookie-protected data (e.g. mail.google.com) from any SWF on the internet that's running in your browser.